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ABSTRACT 


The embodiments of the present invention teaches a system 
and method which allows card issuers to securely add 
.apphcations"duringlhe^lifelimrof the"^^ 
(^eady been issued^(p_cfeU The system and method 

according to embodiments of the present invention allows 
the loading of an application and/or objects from an appli- 
cation server via a card acceptance device and its supporting 
system infrastructure delivery mechanism, onto a card post 
issuance in a secure and confidential manner. 
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SYSTEM AND METHOD FOR A 
MULTI-APPLICATION SMART CARD 
WHICH CAN FACILITATE A POST- 
ISSUANCE DOWNLOAD OF AN 
APPLICATION ONTO THE SMART CARD 

CROSS REFERENCE TO RELATED 
APPLICATION 

lliis application claims priorily to U.S. provisional appli- 
cation No. 60/061,763 filed Oct. 14, 1997, which is herein 
incorporated by reference. Thus application further claims 
priority to U.S. provisional application No. 60/041,468 filed 
Mar. 24, 1997, which is also herein incorporated by refer- 
ence. 

This application is related to U.S. application Ser. No. 
09/046,993 now U.S. Pat. No. 6,005,942 (VISAP009 or 
VISAPOlO), filed on even date herewith which is also herein 
incorporated by reference for all purposes. 

HELD OF THE INVENTION 

The present invention relates to smart cards. In particular, 
the present invention relates to a system and method for 
providing a multi-application smart card which can facilitate 
a post-issuance download of an application onto the smart 
card. 

BACKGROUND OF THE INVENTION 

A smart card is typically a credit card-sized plastic card 
that includes a semiconductor chip capable of holding data 
supporting multiple applications. 

Physically, a smart card often resembles a traditional 
"credit" card having one or more semiconductor devices 
attached to a module embedded in the card, providing 
contacts to the outside world. The card can interface with a 
point-of-sale terminal, an ATM, or a card reader integrated 
into a telephone, a computer, a vending machine, or any 
other appliance. 

A micro-controller semiconductor device embedded in a 
"processor*' smart card allows the card to undertake a range 
of computational operations, protected storage, encryption 
and decision making. Such a micro-controller typically 
includes a microprocessor, memory, and other functional 
hardware elements. Various types of cards are described in 
"The Advanced Card Report: Smart Card Primer*', Kenneth 
R. Ayer and Joseph F. Schulcr, TThe Schulcr Consultancy, 
1993, 

One example of a smart card implemented as a processor 
card is illustrated in FIG. 1. Of course, a smart card may be 
implemented in many ways, and need not necessarily 
include a microprocessor or other features. The smart card 
may be programmed with various types of functionality, 
including applications such as stored-value; credit/debit; 
loyalty programs, etc. 

In some embodiments, smart card 5 has an embedded 
micro-controller 10 that includes a microprocessor 12, ran- 
dom access memory (RAM) 14, read-only memory (ROM) 
16, non-volatile memory 18, a cryptographic module 22, and 
a card reader interface 24. Other features of the micro- 
controller may be present but are not shown, such as a clock, 
a random number generator, interrupt control, control logic, 
a charge pump, power connections, and interface contacts 
that allow the card to communicate with the outside world. 

Microprocessor 12 is any suitable central processing unit 
for executing commands and controlling the device. RAM 
14 serves as storage for calculated results and as slack 
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memory. ROM 16 stores the operating system, fixed data, 
standard routines, and look up tables. Non-volatile memory 
18 (such as EPROM or EEPROM) serves to store informa- 
tion that must not be lost when the card is disconnected from 
5 a power source but that must also be alterable to accommo- 
date data specific to individual cards or any changes possible 
over the card lifetime. This information might include a card 
identification number, a personal identification number, 
authorization levels, cash balances, credit limits, etc. Cryp- 
10 lographic module 22 is an optional hardware module used 
for performing a variety of crptographic algorithms. Card 
reader interface 24 includes the software and hardware 
necessary for communication with the outside world. A wide 
variety of interfaces are possible. By way of example, 
15 interface 24 may provide a contact interface, a close-coupled 
interface, a remote-coupled interface, or a variety of other 
interfaces. With a contact interface, signals from the micro- 
controller are routed to a number of metal contacts on the 
outside of the card which come in physical contact with 
20 similar contacts of a card reader device. 

Various mechanical and electrical characteristics of smart 
card 5 and aspects of its interaction with a card reading 
device are defined by the following specifications, all of 
which are herein incorporated by reference. 

Visa Integrated Circuit Card Specification, (Visa Interna- 
tional Service Association 1996). 

EMV Integrated Circuit Card Specification for Payment 
Systems, (Visa International Service Association 1996). 

EMV Integrated Circuit Card Terminal Specification for 
Payment Systems, (Visa International Service Association 
1996). 

EMV Integrated Circuit Card Application Specification 
for Payment Systems, (Visa International Service Associa- 

3^ tion 1996). 

Intemational Standard; Identification Cards — Integrated 
Circuit(s) Cards with Contacts, Parts 1-6 (International 
Standards Organization 1987-1995). 

Prior to issuance of a smart card to a card user, the smart 

40 card is initialized such that some data is placed in the card. 
For example, during initialization, the smart card may be 
loaded with at least one application, such as credit or stored 
cash value, a file structure initialized with default values, 
and some initial cryptographic keys for transport security. 

45 Once a card is initialized, it is typically personalized. During 
personalization, the smart card is loaded with data which 
uniquely identifies the card. For example, the personaliza- 
tion data can include a maximum value of the card, a 
personal identification number (PIN), the currency in which 

50 the card is valid, the expiration date of the card, and 
cryptographic keys for the card. 

A limitation of conventional smart cards is that new 
applications typically can not be added to an issued smart 
card. Smart cards are traditionally issued with one or more 

55 applications predefined and installed during the manufac- 
turing process of the card. As a result, with traditional smart 
card implementation, once a card has been issued to a card 
user, the smart card becomes a fixed application card. If a 
new application is desired, the smart card is typically 

60 discarded and a new smart card, which includes the new 
application, is issued. 

It would be desirable to provide a smart card which would 
allow applications to be loaded after the card is issued. 
Further, it is desirable to provide a mechanism to manage the 

65 loading of an application as well as general management of 
the applications on the smart card. Additionally, it is desir- 
able to allow an application provider to keep cryptographic 
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keys confidential from the issuer of the smart card and to FIGS. 3A-3B are block diagrams of examples of software 

securely allow application from different entities to coexist layers according to embodiments of the present invention, 

on a card. PIG. 4 is a flow diagram of an example of a method 

according to an embodiment of the present invention for 
5 installing an application onto an issued smart card utilizing 

Embodiments of the present invention teach a system and a card domain, 

method which allows card issuers to add applications during FIG. 5 is a flow diagram of a method according to an 

the lifetime of the card after the card has already been issued embodiment of the present invention for providing confi- 

(referred to herein as post issuance loading). The process of dential information to an application in a smart card using 
downloading an application after the card has been issued to lO security domains. 

the card holder will be referred to herein as a "secure install" piG. 6 is a flow diagram of an example of a method 

process. according to an embodiment of the present invention for 

The system and method according to embodiments of the installing an application onto an issued smart card utilizing 

present invention allow the loading of an application and/or a card domain. 

objects from an application server via a card acceptance 7Ais a flow diagram illustrating a sequence of card 

device and its supporting system infrastructure delivery jjfg states. 

mechanism, onto a card, post issuance in a secure and run td ^ a^.., a .. ;iK,^t,„«; „ «f 

- , . * ^ ^ HO. 7B IS a How diagram lUustratmg a .sequence or card 

confidential manner. j.^^ ^^^^^^ 

An embodiment of the present invention provides a FIG. 8 is an illustration of an example of a card life cycle, 

system and method for providmg confidential information to „ . „ ,. ^ . r . . 

an application in a smart card. In a multi-application smart ^ ^ ' flow diagram of an example of a method 

card, a privileged application, herein referred to as a security to an embodiment of the present mvenlion for 

domain, is utili/^d as a confidential representative of an a card utilizing a card domain, 

application provider. The security domain can contain cryp- F^G. 10 is a block diagram illustrating mteractions 

lographic keys which can be kept confidential from the between a card domain and a security domain on a smart 

smart card issuer, thus allowing separation of cryptographic card according to an embodiment of the present invention, 

security between the issuer and the application provider. FIGS. IIA and IIB are flow diagrams of an example of 

When a new application is loaded onto a smart card, the a method according to an embodiment of the present inven- 

newly loaded application can utilize its associated security lion for loading an application by using a security domain 

domain's cryptographic service. A privileged application after the smart card has issued. 

representing the issuer, herein referred to as a card domain, FIGS. 12A-12B are flow diagrams of an example of a 

can approve of commands, such as commands for initial- method according to an alternate embodiment of the present 

ization and personalization, by invoking the security invention for loading an appHcation using a security domain 

domain's cryptographic service. In this manner, a post after the smart card has issued. 

issuance download of an application onto the issued smart piG. 13 is a block diagram illustrating an example of key 

card can be accomplished. management and key dependencies for post issuance down- 

A method according to an embodiment of the present load of applications onto the smart card, 
invention for providing confidential information to an appli- 
cation in a smart card is presented. The method comprises DETAILED DESCRIPTION OF THE 
the steps of providing a first application in the smart card, the PREFERRED EMBODIMENTS 
first application including a cryptographic service; loading a iiie following description is presented to enable one of 
second application onto the smart card; and installing the ordinary skill in the art to make and to use the invention and 
second application, wherein the cryptographic service of the is provided in the context of a patent application and its 
first application is utilized to install the second application. requirements. Various modifications to the preferred 

In another aspect of the invention, a system according to embodiments will be readily apparent to those skilled in the 

an embodiment of the present invention for providing con- art and the generic principles herein may be applied to other 

fidential information to an application in a smart card is embodiments. Thus, the present invention is not intended to 

presented. The system comprises a first application associ- be limited to the embodiment shown but is to be accorded 
ated with the issued smart card, wherein the first application 50 the widest scope consistent with the principles and features 

includes cryptographic service; and a second application described herein. 

associated with the issued smart card, the second application FIG. 2 is a block diagram of an example of software layers 

being in communication with the first application, wherein which can be utilized in a smart card. Ti hc^smartigrd-shown^ 

the cryptographic service included in the first application is ig^^njludbilir'oper^^ 
utilized for at least one function related to the second 55 ^on^p^r^ninfm^^ 

application. In yet another aspect of the invention, a method •20ffeo'8B7bpeTating^s>^tfe^^^ 

according to an embodiment of the present invention for iiy to control the cards, memory management, input/output 

providing an application to a smart card is presented. The (i/o), and cryptographic features. Card API 204 utilizes the 

method comprising the steps of issuing a smart card; loading instructions from operating system 200 and writes these 

a first application onto the issued smart card; and initiahzing instructions into blocks which can be reused for common 

the first application. routines in multiple applications. Applications 206A and 

206B can run on the smart card via instructio ns fro m API 
204.j|he s g^lj "pUca.t ^ ^ 

FIG. 1 is a block diagram of a smart card system suitable ^c^^u^oXsi liart^Wr^ s^^^ va T uc^ credit , debit7> 

for implementing the present invention. 65 (tr^sil^^andjloyaUJ^ 

FIG. 2 is an example of a block diagram of software layers One embodiment of the present invention is based upon 

which can be utilized in a smart card. the^^|^fr9'stanaafd. In this case applications are referred 
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10 as * Applets* and they are^ntfen:lo:UnkHo:a:Jaya„Card APi 
which is the applicalioD programming interface present on 
smart cards built to the Java Card standard. 

Although the conventional software system shown in 
FIG. 2 allows for multiple applications, it does not solve the 
problem of how to load, securely, an application after 
issuance of the smart card to a user. If an application is to be 
loaded post issuance, a mechanism is needed to manage the 
loading of an application as well as general management of 
the applications on the smart card. Additionally, an appli- 
cation provider may wish to keep cryptographic keys con- 
fidential from the issuer of the smart card. Accordingly, a 
mechanism is needed to provide for the separation of 
confidential information between an application provider 
and an issuer of a smart card. Embodiments of the present 
invention address such a need. 

FIGS. 3A-3B are block diagrams showing software com- 
ponents of a smart card according to embodiments of the 
present invention. The arrows indicate dependencies 
between components. FIG, 3 A shows an embodiment of a 
smart card utilizing a card domain, while FIG. 3B shows an 
embodiment of a smart card utilizing a security domain, as 
well as a card domain. 

The example shown in FIG. 3 A includes an operating 
system 300, a card API 304, applications 305A-305C, a card 
domain 308, and open platform (OP) API 306. The system 
shown in FIG. 3 allows for a secure and managed post 
issuance download of an application onto a smart card. 

Open platform API 306 classifies instructions into card 
domain 308 and security domains 310A-310B (shown in 
FIG. 3B). Accordingly, OP API 306 facilitates the formation 
of instructions into sets which can be identified as being 
included as part of card domain 308 and security domains 
310A-310B. 

Applications 305A-305C can include any application 
which can be supported by a smart card. Examples of these 
applications include credit, debit, stored value, transit, and 
loyalty. Applications 305A-305C are shown to include 
command interfaces, such as APDU interfaces 354A-354C 
which facilitate communication with the external environ- 
ment. 

Applications 305A and 305B can nm on the smart card via 
instructions from card API 304. Card API 304 is imple- 
mented using the instructions from the card operating sys- 
tem and writes these instructions into blocks which can be 
reused for common routines for multiple applications. Those 
skilled in the art will recognize that a translation layer or 
interpreter may reside between API 304 and operating 
system 300. An interpreter interprets the diverse hardware 
chip instructions from vendor specific operating system 300 
into a form which can be readily utilized by card API 304. 

Card domain 308 can be a "privileged" application which 
represents the interests of the smart card issuer. As a 
"privileged" application, card domain 308 may be config- 
ured to perform multiple functions to manage various 
aspects of the smart card. For instance, card domain 308 can 
perform functions such as installing an application on the 
smart card, installing security domain s 310A-310B (shown 
on FIG. 3B), personalization and reading of card global data, 
managing card life cycle stales (including card blocking), 
performing auditing of a blocked card, maintaining a map- 
ping of card applications 305A-305C to security domains 
310A-310B, and performing security domain functions for 
applications 305A-305C which arc not associated with a 
security domain 310. 

Card domain 308 is shown to include an API interface 350 
and a command interface, such as Application Protocol Data 
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Unit (APDU) interface 352. APDU interface 352 facilitates 
interfacing with the external environment. In compliance 
with, e.g., International Standards Organization (ISO) Stan- 
dard 7816-4, entitled "Identification Cards — Integrated 
5 circuit(s) cards with contacts — Part 4, Inter-industry com- 
mands for interchange," which is herein incorporated by 
reference. 

For example, APDU interface 352 can be used during post 
issuance installation of an application or during loading of 
^0 card global data. An application load and install option is 
performed via a set of appropriate APDU commands 
received by card domain 308. API interface 350 facilitates 
interfacing with the internal smart card environment. For 
example, API interface 350 can by used if card domain 308 
^5 is being utilized as a default in place of a security domain 
310, or if an application requires information such as card 
global data, key derivation data, or information regarding 
card life cycle. 

Memory allocations have been performed by the time an 
application is in an install state. An application is also 
personalized after loading and installing. A personalized 
application includes card holder specific data and other 
required data which allows the application to run. In addition 
to managing the installation and personalization of the 
application, card domain 308 can also manage global card 
information. Global card information includes information 
that several applications may need to perform their 
functions, such as card holder name and card unique data 
utilized in cryptographic key derivations. Card domain 308 
can be a repository for the global card information to avoid 
storing the same data multiple times. 

Card domain 308 can also manage card life cycle states 
including card blocking. The smart card will typically move 
25 through several states during its life cycle. Card domain 308 
keeps track of what state the card is in during its life cycle. 
Card domain 308 may also manage a block request to block 
virtually all functions of the card. Further details of card 
domain 308 management of a block request will be dis- 
cussed in conjunction with FIG. 6. Card domain 308 may 
also keep track of the state of an application during an 
application's life cycle. This kind of information regarding 
an application can be utilized during an auditing of a card. 
Auditing can be performed at any time during a card's 
lifetime. For instance, auditing may be performed after a 
card has been blocked or prior to installing a new application 
to validate the card contents. Although virtually all card 
ftinclions are no longer functioning when a card is blocked, 
an issuer may be able to query card domain 308 for 
information regarding a state of an application or the life 
cycle state of the card. In this manner, the issuer of a card 
may still access a profile of the blocked card and its 
applications. 

FIG. 3B shows an embodiment of the present invention 
55 utilizing a security domain 310, as well as card domain 308. 
The example shown in FIG. 3B includes a operating system 
300', a card API 304', applications 305A-305C', security 
domains 310A-310B', a card domain 308', and open plat- 
form (OP) API 306', The system shown in FIG. 3B also 
allows for a secure and managed post issuance download of 
an application onto a smart card. 

Card domain 308' can work in conjunction with a security 
domain 310. Security domain 310 is a logical construct that 
can be implemented as an application to provide security 
65 related functions to card domain 308' and to applications 
associated with security domain 310. Security domains 
310A-310B can assist in secure post issuance loading of an 
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application onto the smart card. Security domains 
310A-310B provide for a mechanism which keeps the 
application provider's confidential information, such as 
cryptographic keys, from being disclosed to the issuer of the 
smart card. 

There may be multiple security domains 310 on a smart 
card, each represented by a unique cryptographic relation- 
ship. A security domain 310 is responsible for the manage- 
ment and sharing of cryptographic keys and the associated 
cryptographic methods which make up the security 
domain's cryptographic relationship. An application which 
is loaded to the smart card post issuance can be associated 
with a security domain, preferably with only one security 
domain. However, multiple applications may be associated 
with the same security domain 310. Applications installed 
on a smart card during the pre- issuance phase may option- 
ally be associated with a security domain 310 on the smart 
card for purposes of loading confidential personalization 
data to those applications using security domain 310 keys. 

The software for security domain 310 may be installed by 
the card manufacturer at the time of card manufacturing 
(e.g., when the ROM is masked), or may be added during 
initialization or personalization stages. Security domains 
310 can be implemented as selectable applications which are 
isolated from one another and the rest of the system. If 
security domain 310 is implemented in a Java card as an 
application, standard Java card security can be relied upon 
to ensure isolation of security domain 310. In addition, or 
alternatively, other security mechanisms such as hardware 
security which can be utilized through OP API 306 imple- 
mentation. OP API 306 may utilize special security features 
to enforce isolation of security domain 310. An example of 
such a security feature is the utilization of chip hardware 
security routines which may be employed by OP API 306. 

Each security domain 310A-310B provides a command 
interface, such as an Application Protocol Data Unit 
(APDU) interface 320A-320B, for communication off card 
and an on card API interface 322A-322B. 

The APDU interface 320A-320B consists of personaliza- 
tion commands and is intended to allow the initial loading of 
security domain keys and to support key rotation if desired 
during the life of the security domain. API interfaces 
322A-322B may include a signature verification method 
and decryption method which are shared with card domain 
308' for post issuance loading of applications. Additionally, 
applications may utilize API interfaces 322A-322B for 
decrypting application confidential data. Note that card 
domain 308' may always function as a security domain and 
does so as the default. 

Security domain 310 manages signing and decrypting 
keys and provides cryptographic services using those keys. 
Security domain 310 processes APDU's for numerous func- 
tions. These functions can include key management func- 
tions e.g.. functions to load or update keys. During Secure 
Installation of an application, security domain 310 can 
provide services to card domain 308' to decrypt an applica- 
tion install file and check the signature of an application file. 
For an application associated with a security domain 310, 
that application's security domain 310 provides decrypt and 
signature functions, such as MACing on an update key 
APDU command during the personalization phase of a 
newly installed application. '^Thereafter, the application can 
use the updated key to decrypt and check signatures on 
subsequent key updates. 

The smart card issuer may decide whether security 
domain 310 utilizes a static key or a session key for 


20 


25 


transactions. Astatic key is a cryptographic key which exists 
prior to processing APD Us and which exist during and after 
the processing of APDUs. A session key is a cryptographic 
key which can be generated for a particular transaction and 
5 is typically no longer used for APDU processing after the 
transaction. If a session key is utilized, security domain 310 
preferably derives its own session key for processing 
APDUs. 

FIG. 4 is a flow diagram of a method accordingly to an 
^0 embodiment of the present invention for providing an appli- 
cation onto a smart card. The example illustrated in FIG. 4 
also applies to installing a security domain 310 onto a smart 
card. Note that all of the flow diagrams in this application are 
merely examples. Accordingly, the illustrated steps of this 
^5 and any other flow diagram herein, can occur in various 
orders and in varying manners in order to accomplish 
virtually the same goal. 

A smart card is issued (step 400), and an application is 
forwarded to the issued smart card (step 402). The forward- 
ing of the application can occur through any electronic 
media which can interface with a smart card and connect to 
an appropriate network. For example, devices such as an 
automatic teller machine (ATM), a display phone, or a home 
computer, can be used to forward an application to the issued 
smart card. The forwarded application is then loaded onto 
the smart card, wherein the loading of the application is 
managed by card domain 308 (.step 404). 

FIG, 5 is another flow diagram of a method according to 
an embodiment of the present invention for providing an 
application onto an issued smart card. A smart card is created 
and provided with a first application, the first application 
including a cryptographic service (step 1002). A second 
application is loaded onto the smart card (step 1004). 
22 Thereafter, the second application is installed, wherein the 
cryptographic service of the first application is utilized to 
install the second application (step 1006). 

FIG. 6 is another flow diagram of an example of a method 
according to an embodiment of the present invention for 
40 providing an application onto an issued smart card, 'l^is 
method for providing an application also applies to provid- 
ing a security domain 310 onto the smart card. In the 
example shown in FIG. 6, a card issuer deploys smart cards 
to customers (step 500). A decision is made to instaU vendor 
45 A's application onto the issued smart card (step 502). When 
a dialogue between the issuer and the smart card is initiated, 
a pre-signed copy of the application is forwarded to the 
smart card (step 504). As previously stated, the dialogue 
between the issuer and the smart card can occur via any 
50 electronic device which can interface with a smart card and 
connect to an appropriate network. The application can be 
pre-signed with a key equivalent to that which already exists 
on the card so that each application has a unique signature 
that can be verified by the card. 
55 Card domain 308 can then take the steps to load the 
application. Card domain 308 decrypts the forwarded appli- 
cation and checks the signature of the application (step 508). 
Card domain 308 can decrypt the application with the 
issuer's secret key. An appropriate cryptography method, 
60 such as Data Encryption Standard (DES) or 3DES, can be 
utilized to decrypt at least a portion of the application. Those 
skilled in the art will recognize that a number of crypto- 
graphic techniques may be used to implement embodiments 
of the present invention. For the purpose of illustration, 
65 symmetric key techniques are addressed herein, although 
asymmetric techniques are also contemplated. A good gen- 
eral cryptography reference is Schneier, Applied 
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Cryptography, 2d Ed. (John Wiley, 1996), the contents of 
which are incorporated herein by reference. 

It is then determined whether the signature on the appli- 
cation is valid (step 510). If the signature associated with the 
application is not valid, then the application is not loaded 
onto the card and the process ends (step 520). If, however, 
the signature associated with the application is valid the 
application is then installed and available for personaliza- 
tion. During personalization the application receives person- 
alization data (step 512). Personalization data includes data 
which is unique to the smart card user. For instance, in a 
airline loyalty application, personalization data can include 
the smart card user's seating preference, meal preference, 
and eligibility for various possible perks. This personaliza- 
tion data can also be signed and encrypted. 

The application then invokes card domain's 308 decryp- 
tion service (step 513). Card domain 308 can then performs 
a signature check (step 514). Methods of decrypting per- 
sonalization data and performing signature checks are well 
known in the art. Finally, the application can then be 
activated (step 518). 

A new application which as been downloaded onto a 
smart card post-issuance can be stored in a variety of ways. 
One example is to store the application into a file. Another 
example is to maintain a pointer to the application object. 

FIG. 7A is a flow diagram illustrating an example of a 
sequence of card life stales. The sequence is preferably 
considered irreversible. The first card life state is when the 
smart card is Masked (700). During the Masked state (700), 
the smart card obtains its operating system, card 
identification, and preferably at least one application. The 
Masked state (700) is achieved as soon as all of the neces- 
sary components for card initialization are made available. 
An example of when necessary components are made avail- 
able is when card domain 308 and OP API 306 are enabled, 
as well as the Java card environment being enabled, such as 
Java card virtual machine 302 and Java card API 304 (both 
of FIG. 3). 

After the Masked state, the next state is the Initialized 
(step 702) state. The Initialized state is achieved once all 
card activity requiring an initialization key is complete. As 
part of card initialization, if not already available, the card 
domain 308 application must be installed and registered. In 
addition, one or more security domains may also be installed 
and registered, lliese installed domains must then be 
selected and personalized. An initialization key is a secret 
key which is typically u.sed by a smart card manufacturer 
during loading of data onto the smart card prior to issuance. 

The next state is Load Secured (step 704). The Load 
Secured state is achieved after a secure install (post- issuance 
download) mechanism for loading of applications through 
the remainder of the card lifetime has been established. 

The final card life state is when the card is either expired 
or blocked (step 706). The blocked state is achieved as soon 
as an authorized smart card application has received a 
command to block the card. 

The card life cycle is preferably an irreversible sequence 
of states with increasing security. Initialization and all 
subsequent card life cycle states and their transition are 
preferably under the control of card domain 308. Card 
domain 308 executes and responds to commands that result 
in a transition in a card life cycle from one state to the next. 
These commands are preferably Application Protocol Data 
Unit (APDU) commands. Card domain 308 is also respon- 
sible for the installation of applications on the card, but 
preferably has no control over the applications' life cycle 
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States. Each application is preferably responsible for its own 
application life cycle state management but it preferably 
allows card domain 308 to have access to its life cycle states 
for auditing purposes. 

5 The Card Life cycle is designed in such a way to increase 
the level of security enforced by the card at each successive 
state. As stated above, the cycle is also established as a 
process which can only ratchet forward to ensure that once 
the card begins a life cycle state with associated security 

jQ policies, the only option is to cycle forward to the next stale 
in the life cycle with a higher level of security. The Card 
Domain as the system security manager of the card main- 
tains the current life cycle state, enforces the associated 
security policies, and controls the state transitions in the 
Card life cycle. 

15 

FIG. 7B is a flow diagram illustrating an example of a 
sequence of an application life cycle. The application is 
initially unavailable (step 750). The next state is a loaded 
state (step 752). The application reaches the loaded state 
once the application has been loaded onto the smart card. 

20 The application is then installed (step 754), and registered 
(step 756). Once the application is registered, it can be 
deleted at any time thereafter. The next state is the person- 
alized stale, wherein personalized information is included in 
the application (step 758). Finally, the application may 

25 expire or be blocked (step 760). 

FIG. 8 is an illustration of an example of multi-application 
card life time line. This time line starts with a Masked ROM 
stage 800 and ends with a card blocked/expired stage 802. 
At Masked ROM stage 800, applications A, B, C and D are 

3Q shown to be installed. This example shows applications A 
and B being installed at a masking stage of the card, 
applications C and D being installed at initialization stage, 
and applications D and F being installed post issuance. 
In this example, application A can be installed in ROM 

35 and used during the complete life of the card from Masked 
ROM stage 800 to card blocked/expired stage 802. Appli- 
cation B is also in ROM and utilized during a first portion 
of the life of the smart card. The life of application B is 
ended at stage 804 A. Application C is located in non-volatile 

40 memory, such as EEPROM, which is loaded during initial- 
ization. Application C is shown to expire at stage 804B. 
Application D is also located in EEPROM and is used for the 
complete life of the card until card blocked/expired stage 
802, Application E is installed at stage 806A, sometime after 

45 issuance of the smart card. Application E is located in 
EEPROM and used until the end of the card life at card 
blocked/expired stage 802. Application F is also installed 
post issuance al stage 806B, and expires sometime before 
the end of the card life at stage 804C. 

50 FIG. 9 is a flow diagram of a method according to an 
embodiment of the present invention for blocking a card. A 
card be can be blocked if a breach of security is detected by 
an application. According to an embodiment of the present 
invention, a smart card can be blocked while an application 

55 is in use. A blocked card will no longer operate so that a 
suspect user cannot utilize any of the applications on the 
smart card. Blocking is merely one example of the many 
functions card domain 308 can perform in managing the 
other applications on the smart card. Examples of other 

60 functions include installing an application on the smart card, 
installing security domains 310A-310B, personalization and 
reading of card global data, managing card life cycle states 
including card blocking, performing auditing of a block 
card, maintaining a mapping of card applications to security 

65 domains, and performing security domain functions for 
applications which are not associated with a security 
domain. 
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In the example shown in FIG. 9, an application is cur- 
rently in use (step 600). The application delects a problem 
which triggers a card block request from the application 
(step 602). The application then sends a card block request 
to card domain 308 (step 604). Card domain 308 determines 
whether the card block request is valid (step 606). A card 
block request can be valid if the request originates from a 
predetermined application. If the card block request is not 
valid, the card domain 308 does not block the smart card 
(step 608). However, if the card block request is valid, then 
card domain 808 authorizes the card blocking (step 610), 
and card domain 308 blocks the smart card (step 612) such 
that the smart card will reject any attempted transactions for 
any of the applications on the card. 

FIG. 10 is a block diagram illustrating the use of security 
domain 310 by the card domain 308. The method and system 
according to an embodiment of the present invention allows 
for multiple application providers to be represented on a 
smart card in a secure and confidential manner. This security 
and confidentiality can be achieved through the use of 
security domain 310A-310B shown in FIG. 3. 

FIG, 10 illustrates an example of a smart card which 
contains two security domains 310A-310B. In this example, 
it is assumed that a masked application 305A from the smart 
card is associated with a security domain, such as security 
domain 310A, and an additional application 305B will be 
added post issuance and be associated with a second security 
domain, such as security domain 310B. The arrows indicate 
key relationships between the various smart card entities. 
Masked application 305A uses key services from security 
domain 310A for decrypting confidential data and optionally 
for full personalization. Card domain 308 uses key services 
from security domain 310B for decrypting and checking the 
signature of an application loaded post issuance, such as post 
issuance loaded application 305B. Post issuance loaded 
application 305B uses key services from security domain 
310B for decrypting confidential data and optionally for full 
personalization. 

FIGS. IIA and IIB are further flow diagrams of an 
example for a method according to an embodiment of the 
present invention for providing an application onto an issued 
smart card. The card issuer decides to include a security 
domain 310 onto a smart card (step 1100). The issuer assigns 
security domain 310 to vendor A (step 1102). Vendor A, or 
an application developer on behalf of vendor A, generates 
cryptographic keys such as those used in symmetric or 
asymmetric cryptography operations (step 1104). Examples 
of these cryptography operations include encryption, 
decryption, MACing, Hashing, and digital signatures. 
Examples of cryptographic methods which utilize such keys 
and are suitable for implementation for the embodiment of 
the method and system of the present invention include Data 
Encryption Standard (DES) and 3DES. The card personal- 
ization agent receives the keys and loads security domain 
keys associated with a specific security domain 310 for each 
smart card (1106). The card personalization agent receives 
smart cards and collects other data, such as application and 
card holder specific data, and places data on the smart card 
(step 1108). 

The card issuer then deploys the smart card to customers 
(step 1110). A decision is then made to install vendor A's 
application on the smart card (step 1112). When a dialogue 
between the smart card issuer and the smart card is initiated, 
a signed copy of the application is forwarded to the smart 
card (step 1114). The application can be signed with a key 
equivalent to that which already exists on the smart card so 
that each application has a unique signature that can be 
verified by the smart card. 


The smart card's card domain 308 then lakes steps to load 
the application. Card domain 308 invokes an associated 
security domain's cryptographic service to decrypt the appli- 
cation and check the signature (step 1118). It is then deier- 

5 mined if the signature is valid (step 1120). If the signature 
is not valid, the process ends (step 1122). If, however, the 
signature is found to be valid, then the application receives 
personalization data which can be signed and optionally 
encrypted (step 1124), The loaded application then invokes 
its associated security domain's decryption service and 
signature check (step 1126). Secret keys required to run or 
operate the application on the smart card arc used to activate 
the application by authentication (step 1130). 

FIGS. 12A and 12B are flow diagrams of a method 
according to another embodiment of the present invention 
for providing confidential information to an application 
using a security domain 310. The issuer decides to include 
a security domain 310 on a smart card (step 1200). A trusted 
party generates secret cryptographic keys and sends the keys 
to a card personalization agent in a secure manner (step 
1201). A trusted party is typically a third parly who performs 
the function of certifying the source of information, such as 
a signature. A card personalization agent (which may be the 
same as the trusted party) receives the key and loads a 

2j unique secure domain key associated with a specific security 
domain 310 for each smart card (step 1202). 

The card personalization agent receives the smart card 
and collects other data, such as application and card holder 
specific data, and places the data on the smart card (step 

3Q 1204). The issuer then deploys the sman card to its custom- 
ers (step 1206). A decision is made to install vendor A's 
application on the issued smart card (step 1208). Vendor A 
obtains secret keys for security domain 310 from the trusted 
party (step 1210). Vendor A then sends the smart card issuer 

35 a signed copy of Vendor A's application (step 1212). 

When a dialogue between the smart card issuer and the 
smart card is initiated, a signed copy of the application is 
forwarded to the smart card (step 1214). The application can 
be signed with a key equivalent to that which already exists 

40 on the smart card so that each application has a unique 
signature that can be verified by the smart card. Card domain 
308 invokes security domain's cryptographic service to 
decrypt the associated application and check its signature 
(step 1218). It is then determined whether the signature is 

45 valid (step 1220). If the signature is not valid, then the 
process ends (step 1222). 

If, however, the signature is valid, then the application 
receives personalization data, which can be signed and 
optionally encrypted (step 1224). The loaded apphcation 

50 then invokes security domain's decryption service and sig- 
nature check (step 1226). The cryptographic secret data 
required to run or operate the application on the card arc 
used to activate the application (step 1230). 

FIG. 13 is a block diagram illustrating the u.se of cryp- 

55 tographic keys for post issuance loading of an application 
onto a sman card. Applications that are not masked and not 
loaded during card initialization stage or personalization 
stage need their cxccutablcs downloaded using a secure 
installation method, such as the post issuance download 

60 described in previous Figures. The applications can be 
loaded using the card domain cryptographic keys. The 
applications are then decrypted and can have their signature 
verified using the key services of the corresponding security 
domain 310. Therefore, the desired security doraain(s) 310 

65 preferably have encryption and signature keys installed prior 
to the post issuance download of the corresponding appli- 
cation. 
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In the example shown in FIG. 13, only one security 
domain 310 is shown since security domains 310 for other 
applications are not relevant to illustrate the downloading of 
a single application. Note that the result of the secure 
installation is initially a loaded application, which must then 
be installed, registered and personalized. After loading, the 
application is installed, preferably by issuing an install 
APDU command to card domain 308. An application can be 
installed when its install method has executed successfully. 
Memory allocations have been performed by the time an 
application is in an install state. A loaded application should 
also be registered. When an application is registered, it is 
selectable and it is ready to process and respond to APDU 
commands. Installation and registration may be performed 
simultaneously by the same APDU command. An applica- 
tion is also personalized after loading. A personalized appli- 
cation includes card holder specific data and other required 
data which allows the application to run. 

In the example shown in FIG. 13, the cryptographic key 
and MAC/Signature key are shown to be included in the 
functions of card domain 308/security domain 310. If a 
security domain is associated with the application being 
loaded, then the security domain will be invoked. However, 
if no security domain 310 is associated with the application 
which is being loaded, then the cryptographic key and the 
signature key of card domain 308 will be utilized. In contrast 
to the install commands sent to the smart card during the 
initialization phase, the post issuance install command is not 
issued in a secured environment, therefore it is preferably 
protected with a cryptographic key, such as a MAC/ 
Signature key. Card domain 308 manages the post-issuance 
loading of a new application, while secure domain 310 
ensures the validity and integrity of the new application once 
the new application has been loaded onto the smart card. If 
a secure domain 310 is not associated with the newly loaded 
application, then card domain 308 performs secure domain's 
310 functions. Once the new application is post-issuance 
downloaded, various keys, such as an cryptographic key and 
a signature key. are preferably utilized for installation and 
personalization of the appHcation. 

A method and system for a smart card domain and a 
security domain has been disclosed. Software written 
according to the present invention may be stored in some 
form of computer-readable medium, such as memory or 
CD-ROM, or transmitted over a network, and executed by a 
processor. 

Although the present invention has been described in 
accordance with the embodiment shown, one of ordinary 
skill in the art will readily recognize that there could be 
variations to the embodiment and these variations would be 
within the spirit and scope of the present invention. 
Accordingly, many modifications may be made by one of 
ordinary skill in the art without departing from the spirit and 
scope of the appended claims. 

What is claimed is: 

1. A smart card comprising: 

a card life cycle having a plurality of states; 

a memory including an indication of which of said states 
said card life cycle is in; and 

a card domain application including 
an issuer key associated with the issuer of said smart 
card, 

a function for managing said life cycle of said smart 
card, and 

a function for tracking the status of said life cycle of 
said smart card, whereby said card domain applica- 
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tion represents the interests of the issuer and man- 
ages said card life cycle. 

2. A smart card as recited in claim 1 wherein said card 
domain application further includes: 

5 a function for blocking said smart card. 

3. A smart card as recited in claim 1 wherein said states 
of said card life cycle include masked, initialized, load 
secured and blocked. 

4. A smart card as recited in claim 1 wherein said states 
10 of said card life cycle are in an irreversible sequence and 

wherein said states of said card life cycle place said smart 
card into an increasing level of security. 

5. A smart card as recited in claim 1 wherein the contents 
of said memory determines the state of said card life cycle. 

15 6. A method of blocking a smart card comprising: 

detecting a problem with said smart card by an application 

of said smart card; 
sending a card block request from said application to a 

card domain application of said smart card, said card 

domain application having the capability to block said 

smart card; 

determining by said card domain application whether said 
card block request is valid; and 
25 blocking said smart card by said card domain application, 
whereby said smart card is not operational for a user. 

7. A method as recited in claim 6 wherein said card 
domain application includes an issuer key associated with 
the issuer of said smart card, whereby said card domain 

3Q application represents the interests of the issuer. 

8. A method of moving a smart card through a sequence 
of card life cycle states, said method comprising: 

receiving said smart card in a masked state, said masked 
state indicating that components necessary for initial- 
35 ization are available on said smart card; 

initializing said smart card using an initialization key; 

placing said smart card into an initialized state; 

loading an application onto said smart card post -issuance; 
and 

40 

placing said smart card into a load secured state, whereby 
said smart card passes through a number of said states 
of said card life cycle. 

9. A method as recited in claim 8 further comprising: 
receiving a card block request; 

blocking said smart card; and 

placing said smart card into a blocked state, whereby said 
smart card is not operational for a user. 

10. A method as recited in claim 8 wherein said card life 
50 cycle states are managed by a card domain application. 

11. A method as recited in claim 8 wherein said states of 
said card life cycle are in an irreversible sequence. 

12. A method as recited in claim 8 wherein said states of 
said card life cycle place said smart card into an increasing 

55 level of security. 

13. A smart card comprising: 

a first application having a sequence of life cycle states; 
and 

a card domain application including 
60 an issuer key associated with the issuer of said smart 
card, 

a function for loading said application onto said smart 
card, said loading causing said first application to be 
placed into a loaded state, 
65 a function for installing said application on said smart 
card, said installing causing said first application to 
be placed into an installed state, and 
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a function for registering said application on said smart 
card, said registering causing said first application to 
be placed into a registered state, whereby said card 
domain application represents the interests of the 
issuer and manages said first application. 5 

14. A smart card as recited in claim 13 wherein said card 
domain application further includes: 

a cryptographic service for loading said first application 
onto said smart card post-issuance. 

15. A smart card as recited in claim 13 wherein said first 1° 
application further includes: 

a function for personalizing said first application, said 
personalizing causing said first application to be placed 
into a personalized state, whereby said personalizing is 
under the authority of said first application. 

16. A smart card as recited in claim 13 wherein said first 
application further includes: 

a function for blocking said first application, said block- 
ing causing said first application to be placed into a 
blocked state, whereby said blocking is under the 
authority of said first application. 

17. A method of moving an application of smart card 
through a sequence of application life cycle states, said 
method comprising: 25 

receiving said application on said smart card, said receiv- 
ing placing said application into a loaded stale; 

installing said application on said smart card, said install- 
ing placing said application into an installed state; 

registering said application on said smart card, said reg- 
istering placing said application into a registered state; 

personalizing said application on said smart card, said 
personalizing placing said application into a personal- 
ized state, whereby said application is available for use. 

18. A method as recited in claim 17 further comprising: 
receiving an application block request; 

blocking said application; and 
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placing said application into a blocked state, whereby said 
application is not available for use. 

19. A method as recited in claim 17 further comprising: 
receiving an application delete request; 

deleting said application from said smart card; and 
indicating said application is in a not available state, 
whereby said application is not available for use. 

20. A method as recited in claim 17 wherein said appli- 
cation is received by being loaded into a memory of said 
smart card during initialization of said smart card, whereby 
said application is present on said smart card before issu- 
ance. 

21. A method as recited in claim 17 wherein said appli- 
cation is received by being loaded onto said smart card 
post-issuance, whereby said application appears on said 
smart card after issuance. 

22. A method of moving an application of smart card 
through a sequence of application life cycle states after 
issuance of said smart card, said method comprising: 

issuing said smart card; 

indicating within said smart card that said application is in 
a not available state; 

loading said application onto said smart card post- 
issuance, said loading placing said application into a 
loaded state; and 

installing said application on said smart card, said install- 
ing placing said application into an installed state, 
whereby said application is available for use on said 
smart card. 

23. A method as recited in claim 22 further comprising: 
personalizing said application on said smart card, said 

personalizing placing said application into a personal- 
ized state. 
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ABSTRACT 


A smart card architecture includes a run -time environment, 
a card manager, one or more security domains, a provider 
application and an issuer application. One or more APIs 
provide communication. The life cycle of the card and card 
manager includes states: Pre-production, Ready, Initialized, 
Secured, Locked and Terminated. The life cycle of an 
application includes states: Installed, Selectable, 
Personalized, Blocked, Locked and Deleted. A card registry 
keeps track of card manager and application data elements. 
The functionality of a security domain on a smart card is 
extended to allow it to perform delegated management of 
smart card applications: delegated loading, installation and/ 
or deletion of an application. A provider of an application is 
assiued of more direct control and management of their 
application, yet an issuer still maintains some control over 
the management of the card. The card issuer empowers 
application providers to initiate changes to the issuer's smart 
cards that are pre-approved by the card issuer. A method of 
delegated loading of an application onto a smart card first 
receives a load command from an application provider via a 
card acceptance device. The load command includes an 
indication of an application to be loaded and an appended 
command authentication pattern. Next, the load command is 
verified using the command authentication pattern. Then, an 
application is received from an application provider via the 
card acceptance device; the application also includes an 
appended application authentication pattern which is used to 
verify the application. Finally, the application is loaded into 
memory of the smart card. 

16 Claims, 14 Drawing Sheets 
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DELEGATED MANAGEMENT OF SMARl^ 
CARD APPLICATIONS 

This application claims priority of U.S. provisional 
patent application Nos. 60/105,841, 60/121,810 and 60/124. 
130 filed Oct. 27, 1998, Feb- 25, 1999 and Mar. 12, 1999 
respectively, each entitled "Visa Open Platform Card 
Specification," which are hereby incorporated by reference. 

This application is also related to U.S. patent application 
Sen Nos. 09/046,993 and 09/046,994. 

HELD OF THE INVENTION 

The present invention relates generally to smart cards. 
More specifically, the present invention relates to a tech- 
nique for delegating the management of applications on a 
smart card such as loading, installation and deletion. 

BACKGROUND OF TI IE INVENTION 

Smart card technologies hold great promise as the 
replacement for magnetic stripe card technology, llie adop- 
tion of smart cards, however, on a massive scale has been 
slow to develop. One reason for this slow adoption is the 
lack of standards among the many different vendor imple- 
mentations of smart cards and the difficuUies with imple- 
menting a new technology. 

Recently, significant standards in the smart card area have 
been created. The standards, however, have been primarily 
targeted at either low levels of interoperability, such as the 
mechanical and electrical standards specified in the EMV 
specifications, or at the application layer in terms of devel- 
oping standard chip credit, debit and purse applications. The 
main benefit of the standards has been realized in single- 
application smart cards, but has not significantly improved 
the situation for multi-applications smart cards. 

The mid-1990s saw the introduction of various open 
systems standards for application development. For 
example, three technologies in this area are JAVA Card from 
Sun Microsystems, Inc., Smart Card for Windows from 
Microsoft Corporation, and MULTOS from MAOSCO, Ltd. 
These technology standards provide an important part of the 
solution toward common programming standards allowing 
application portability between different manufacturers card 
implementations. Other recent efforts have also addressed 
particular issues with multi-application smart cards. For 
example, U.S. patent application Ser. No. 09/046,994 filed 
Mar. 24, 1998, and U.S. patent application Ser. No. 09/046, 
993 filed Mar. 4, 1 998 addre.ss issues related to post- issuance 
downloading and life cycle, each of which are hereby 
incorporated by reference. 

In prior art smart cards only the issuer of the card has been 
allowed to perform certain management functions of appli- 
cations such as loading an application onto the card, install- 
ing the application and deleting the application from the 
card. This reliance upon the i.ssuer exclusively for loading, 
installing and deleting applications can lead to some diffi- 
culties. For example, should a store develop a loyalty 
application for its customers that it wishes to load and install 
onto their customer's smart cards, the store would be pre- 
cluded from doing so if only the card issuer is allowed to 
perform such functions. Arranging for the store to contact 
the issuer, and anranging for the issuer to load the store's 
application onto its customer's smart cards presents basic 
logistical problems such as application security and access 
to cards. For example, it would be best if the store could 
download an application onto a customer card while the 
customer visited the store. If only the issuer can download 
the appUcation, it becomes more difficult to access the 
customer card. 
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In addition to logistical problems, there are privacy issues 
with regard to an application developer's private customer 
data. For example, if a loyalty application of a particular 
third party is loaded onto a smart card by the issuer, it may 

5 be still necessary to add private customer-specific data onto 
each individual card for use by loyalty application. This 
private customer information may very well be the private 
property of the third party, and the third party may be 
unwilling to transfer this private information to a card issuer 

10 to allow the card issuer to load and install the third party's 
loyalty data. For instance. Hertz would likely be unwilling 
to provide private customer information regarding it top 
renters to the bank that is loading Hertz's application onto a 
smart card. 

^5 Other mechanical difficulties are presented should a cus- 
tomer desire to download and install a third party's appli- 
cation at the third party's site if only the issuer is allowed to 
download and install an application. For example, should a 
customer wish to download a loyahy application while at the 

20 third party's place of business during a smart card 
transaction, it would be first be necessary for the card 
acceptance device to connect to the issuer host to download 
the loyalty application, and then connect to the third party's 
host computer in order to receive custom information for the 

25 initialization and personalization of that application. Such 
multiple connections at load time make the transaction more 
complex, time consuming and are more prone to failure. In 
addition, as a practical matter, should a customer wish to 
download and install an application onto his smart card, it is 

30 more than likely that the customer is physically present at a 
third party site rather than at the issuer's site. 

Further difiSculties may be encountered if only the issuer 
is allowed to delete an application that belongs to the 
application provider/developer from a customer smart card. 
For example, the application is the responsibility of the 
application provider and is his liability. Should an agreement 
expire between the provider and the issuer, it may be more 
desirable for the provider to be able to delete his properly 
(the application) from the smart card, rather than relying 

^° upon the issuer to do so for him. A further difficulty 
encountered if only the issuer is allowed to delete an 
application relates to the application data. When an appli- 
cation is deleted, the application data is deleted as well. 
Therefore, it would be desirable to allow the application 
provider to extract any relevant data (e.g., loyalty points 
from a loyalty application) from the card before the appli- 
cation is deleted. Since the card issuer does not have the 
provider's application keys, it would be near impossible for 
the card issuer to extract any information that required any 
kind of authentication. (The provider may also not desire 
that the issuer have access to the extracted information.) 

ITierefore, it would be desirable to allow another entity 
besides the card issuer to manage various functioas associ- 
ated with card applications such as loading, installing and 
deleting. It would further be desirable to allow the issuer to 
still be able to manage and control which applications are 
present on the smart card. 

SUMMARY OF THE INVENTION 

60 

To achieve the foregoing, and in accordance with the 
purpose of the present invention, a technique is disclosed 
that extends the functionafity of a security domain and 
allows it to perform delegated management of smart card 
65 applications. For example, embodiments of the present 
invention allow a security domain to perform delegated 
loading, installation and/or deletion of an application. By 
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delegating this management to their security domain, a FIG. 7C is a flow diagram describing one embodiment of 

provider of an application is assured of more direct control the download application step of FIG. 7A. 

and management of their application, yet an issuer still fiQ 70 is a flow diagram describing the install applica- 

maintains some control over the management of the card. tion step of FIG. 7A. 

This concept of delegated management allows the card 5 pj^g g g illustrate examples of a load and an install 

issuer the option of empowering application providers to command that may be created in steps 346 and 352 of FIG. 

initiate changes to the issuer's smart cards that arc pre- 73, 

approved by the card issuer. This pre-approval ensures that iUustrates a load file containing an application 

only card content changes that the card issuer has approved according to one embodiment of the invention, 

will be accepted and processed by a card manager of a smart ... ... ... .... 

card. This delegation of control in the card update process H illustrates an embodiment in which an application 

allows application providers more flexibility in managing "^^V downloaded from an application provider host 

their own applicatioas on the card i^^suer's cards. ^°">P^^^^ ^ ^^^^^ ^''^ ^ ^^^^S^^^^ 

In one embodiment, a method of delegated loading of an ^}^- |f ,^ f'^'^'' ' ^^^^"^^^"^ 

application onto a smart card first receives a load command performing delegated deletion. 

from an application provider via a card acceptance device. FIGS. 13 and 14 illustrate a computer system suitable for 

The load command includes an indication of an application implementing embodiments of the present invention, 
to be loaded and an appended command authentication 
pattern. Next, the load command is verified using the 
command authentication pattern. Then, an application is 

received from an apphcation provider via the card accep- The present invention is suitable for use with either single 

tance device; the application also includes an appended or multi-application smart cards. A multi-application smart 

application authentication pattern which is used to verify the card may come from a variety of manufacturers and may use 

application. Finally, the application is loaded into memory any of a number of operating systems. By way of example, 
of the smart card. Thus, an application provider is allowed ^ a smart card may use the JAVA Card operating system or the 

to load an application onto a smart card. Smart Card for Windows operating system. As used herein. 

In another embodiment, a system for delegated loading of "smart card" refers to any of these single-application or 

an application onto a smart card includes a host computer multi-application smart cards. In one particular 

under control of an application provider and a software embodiment, the present invention works well with the 

application to be loaded onto a smart card. The application "Open Platform" architecture as defined in Open Platfonn 

includes an appended application authentication pattern pro- Card Specification Version 2.0, Apr. 19, 1999, available 

duced by an issuer of the smart card that verifies the from \^sa International ServiceAssociati on. ^igj^Eit Sd^j 

application to the smart card. The system also includes a ^ tu'l^igiia ggi^^i^^isjj^ 
smart card acceptance device linked to the host computer 3^ ^^e^i^^^^^5lSQ^5 ^i^fiy/^ a 

and a smart card included in the card acceptance device. The nji^^^^ati!SnfiMiep(^& 

smart card includes code arranged to verify the application The standard provides a common security and card man- 
using the application authentication pattern. Thus, the appli- agement architecture and defines a flexible and powerful 
cation provider is allowed to load the application onto the standard for card issuers to create multi-application smart 
smart card. cards. 

BRIEF DESCRIPTION OF THE DRAWINGS Smart Cards 

The invention, together with further advantages thereof, The present invention is applicable to smart cards. Also 

may best be understood by reference to the following termed chip cards, integrated circuit cards, memory cards or 
description taken in conjunction with the accompanying 45 processor cards, a smart card is typically a credit card-sized 

drawings in which: plastic card that includes one or more semiconductor inle- 

FIG. 1 illustrates symbolically and environment in which grated circuits. A smart card can interface with a point-of- 

thc Open Platform architecture provides benefits for smart sale terminal, an ATM, or with a card reader integrated with 

card holders, issuers, application developers and other cnti- a computer, telephone, vending machine, or a variety of 
ties. 50 other devices. The smart card may be programmed with 

no. 2 iUustrates in further detail the Open Platform various types of functionality such as a slored-value 

architecture as it may be implemented upon a smart card. application, a credit or debit application, a loyalty 

HG. 3 is another illustration of the Open Platform archi- application, cardholder information, eta Although a plastic 

* . cr-io •* ui f 1 ■ • «u * card IS currently the medium of choice for smart cards. It IS 

tecturc of FIG. 2 suitable for explaining the present invcn- , . j .u . . j 1 u • 1 . j - 

^.^^ r o r contemplated that a smart card may also be implemented m 

, a smaller form factor, for example, it may attach to a key 

HG. 4 Illustrates the card manager life cycle state tran- ^^^^^ ^ ^^^^ ^ ^ module. Asmart card may also 

sitions according to one cmbodimcm of the invention. implemented as part of a personal digital assistant, 

no. 5 illustrates application Ufe cycle state transitions telephone (such as a subscriber identification module), or 

according to one embodiment of the invention. take a different form. The below description provides an 

FIG. 6 illustrate a card registry database according to one example of the possible elements of a smart card, although 

embodiment of the invention. the present invention is applicable to a wide range of types 

FIG. 7A is a flow diagram describing a technique for of smart cards, 

performing delegated loading. A smart card may include a microprocessor, random 

FIG. 7B is a flow diagram that describes how an issuer 65 access memory (RAM), read-only memory (ROM), non- 

approves an application for delegated loading and installa- volatile memory, an encryption module (or arithmetic unit), 

tion. and a card reader (or terminal) interface. Other features may 
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be preseot such as optical storage, flash EEPROM, FRAM, 
a clock, a random number generator, interrupt control, 
control logic, a charge pump, power connections, and inter- 
face contacts that allow the card to communicate with the 
outside world. Of course, a smart card may be implemented 
in many ways, and need not necessarily include a micro- 
processor or other features. 

The microprocessor is any suitable central processing unit 
for executing commands and controlling the device. RAM 
serves as temporary storage for calculated results and as 
stack memory. ROM stores the operating system, fixed data, 
standard routines, look up tables and other permanent infor- 
mation. Non-volatile memory (such as EPROM or 
EEPROM) serves to store information that must not be lost 
when the card is disconnected from a power source, and 
must also be alterable to accommodate data specific to 
individual cards or changes possible over the card lifetime. 
This information includes a card identification number, a 
personal identification number, authorization levels, cash 
balances, credit limits, and other information that may need 
to change over time. An encryption module is an optional 
hardware module used for performing a variety of encryp- 
tion algorithms. Of course, encryption may also be per- 
formed in software. Applied Cryptography, Bruce Schneier, 
John Wiley & Sons, Inc., 1996 discusses suitable encryption 
algorithms and is hereby incorporated by reference. 

The card reader interface includes the software and hard- 
ware necessary for communication with the outside world. 
A wide variety of interfaces are possible. By way of 
example, the interface may provide a contact interface, a 
close-coupled interface, a remote -coupled interface, or a 
variety of other interfaces. With a contact interface, signals 
from the integrated circuit are routed to a number of metal 
contacts on the outside of the card which come in physical 
contact with similar contacts of a card reader device. A smart 
card may include a traditional magnetic stripe to provide 
compatibility with traditional card reader devices and 
applications, and may also provide a copy of the magnetic 
stripe information within the integrated circuit itself for 
compatibility. 

Various mechanical and electrical characteristics of a 
smart card and aspects of its interaction with a card reader 
device are described in Smart Card Handbook, W. Rankl and 
W. EflBng, John Wiley & Sons, Ltd., 1997, and are defined 
by the following specifications, all of which arc incorporated 
herein by reference: Visa Integrated Circuit Card 
Specification, Visa International Service Association, 1996; 
E^fV Integrated Circuit Card Specification for Payment 
Systems, EMV Integrated Circuit Card Terminal Specifica- 
tion for Payment Systems, EMV Integrated Circuit Card 
Application Specification for Payment Systems, Visa 
International, Mastercard, Europay, 1996; and International 
Standard; Identification Cards — Integrated Circuit{s) 
Cards with Contacts, Parts 1-6, International Organization 
for Standardization, 1987-1995. 

Card Architecture 

FIG. 1 illustrates symbolically an environment in which 
Open Platform architecture 10 provides benefits for smart 
card holders, issuers, application developers and other enti- 
ties. Although the present invention works well within 
architecture 10, it is also suitable for use in other architec- 
tures. Open Platform architecture 10 embodied within a 
smart card 20 provides card issuers an architecture for 
managing smart cards. Architecture 10 gives card issuers the 
power to manage and change the content of their cards while 
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also offering them the flexibility to share control of their 
cards with other business entities. Preferable, ultimate con- 
trol rests with the card issuer, but through use of architecture 
10 other business entities are allowed to manage their own 

5 applications on the card issuers cards as appropriate. An 
issuer personalizes new cards received from a card supplier 
and then issues these cards to customers. Personalization 
may also be performed by the card supplier or by a person- 
alization bureau. An issuer may be any suitable issuing 
entity such as a bank, financial institution, telecommunica- 
tions network operator, a service association, a merchant or 
other organization, or even an agent acting for an issuer. 

As shown symbolically, in FIG. 1 a wide variety of 
systems and devices benefit through use of architecture 10. 

]5 A smart card 20 has been previously described and its 
relationship with architecture 10 will be further explained 
below. A card acceptance device 22 (also termed card reader 
or terminal) may contain an application that interacts with 
architecture 10 within smart card 20, and can also download 

20 an application onto the smart card. A terminal management 
system 24 manages terminals and their respective applica- 
tions. An application server 26 provides an application for a 
smart card or card reader. A personalization system 28 
personalizes smart card applications. A card management 

25 system 30 manages an issuer's card base and respective 
applications. A key management system 32 provides support 
for pre-issuance and post-Lssuance support for key genera- 
tion and/or key storage and/or key retrieval. Application 
development tools 34 are used to develop smart card appU- 

30 cations. 

FIG. 2 illustrates in further detail Open Platform archi- 
tecture 10 as it may be implemented upon a smart card (not 
shown). Run-time environment 102 includes both the actual 
hardware of the smart card as well as the operating system 

35 of the smart card. Architecture 10 may be implemented on 
top of any card run-time environment. Run-time environ- 
ment 102 is responsible for providing a hardware indepen- 
dent application programming interface (API) for provider 
applications as well as a secure storablc and executing space 

40 for applications, thus ensuring that each application's code 
and data are able to remain separate and secure from others. 
Architecture 10 may be used with any of a wide variety of 
physical smart cards available from a wide variety of 
manufacturers. Further, architecture 10 may be implemented 

45 on top of any suitable smart card operating system, such as 
JAVA Card and Smart Card for Windows, among others. 

Architecture 10 includes a number of components as 
shown in the sample card configuration of FIG. 2. Card 
manager 104 is a software application that represents the 

50 card issuer. It manages the run-time environment for appli- 
cations and controls the overall system and security for the 
smart card. Card manager 104 provides an Open Platform 
API 110 for applications to access its services and an 
external command interface for management of the card by 

55 off-card management systems. In one embodiment of the 
invention, this external command interface is an Application 
Protocol Data Unit (APDU) interface which is an ISO 
standard communication messaging protocol between a card 
acceptance device and its smart card. Further details on the 

60 APDU interface are contained in Open Platform Card 
Specification Version 2.0 referenced above. Other external 
command interfaces such as RPC or RM! may also be 
suitable. Additionally, card manager 104 loads issuer appli- 
cation 112 and performs related card content management 

65 on behalf of the card issuer while also managing the loading, 
installation and deletion of applications provided by appli- 
cation providers. 
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Card manager 104 also performs APDU command dis- 
patching and application section. Card manager 104 
includes an internal card registry 250 as an information 
resource for card management. The card registry contains 
information for managing card, load file and application life 5 
cycle states, card blocking, personal identification numbers 
(PINs), application loading, installation and deletion, and 
the authorization of memory allocation. 

Card manager 104 can also function as an application. It 
has application characteristics such as an application iden- 
tifier (AID), application life cycle slates, and it can select 
itself as the selected application. For example, card manager 
104 functions as an application when the card issuer selects 
the card manager to load a new application onto a new card. 

Card manager 104 is responsible for overall card security 
and includes the security domain application of the card 
issuer which supports key handling, encryption, decryption, 
signature generation and verification for the card issuer's 
applications. Card manager 104 may include a variety of 
cryptographic keys for the smart card to perform these 20 
functions. In a preferred embodiment of the invention, it 
includes at least one set of static symmetric keys including 
an authentication/encryption key, a MAC creation key, and 
a key encryption key. The authentication/encryption key is 
used for the initial mutual authentication of card and host 25 
and for data encryption during regular session processing. 
The MAC creation key is used to calculate data authentica- 
tion patterns for (a) verifying the integrity of data in a 
command data field and (b) verifying the authenticity of a 
command. The key encryption key is used to decrypt keys 3Q 
that are received by the card. Most preferably, a session key 
may be derived from any of the above keys using unique 
card data and session data. In addition to the symmetric key 
set, the card manager may make use of a asymmetric 
cryptography by also including the pubhc key of an issuer 35 
for decrypting information that has been originally been 
encrypted using the private key of the issuer. 

Provider security domains 106 and 108 are special key 
and security management applications that are used to 
ensure separation of keys between the card issuer and 40 
different application providers. For example, security 
domain 106 includes keys for provider application 114 that 
are not revealed to card manager 104, issuer application 112 
or other entities on the card. Security domain 108 contains 
keys unique to another provider application. In this fashion, 45 
a security domain is the on-card representative of an appli- 
cation provider. It provides cryptographic services for all the 
applications on a card that are owned by a particular 
application provider. Alternatively, there may be one secu- 
rity domain for each application on a card. A security 50 
domain may be established on behalf of an application 
provider when the provider requires use of keys on the card 
which should be kept secret from card issuer keys and other 
provider keys. The issuer*s security domain which includes 
the issuer's secret keys are preferably included within card 55 
manager 104. 

Open Platform API 110 provides an interface that pro- 
vides access to services provided by card manager 104 and 
security domain s 106 and 108 fo r_various.applica_lio ns. O pen 

(5131afftffm^:-^4-Bl54^ m>y be- implcnfented in^^y_suitabl^60 

/language^^an d^inj^Q^^ 

Issuer application 112 is an issuer-provided software 
application that performs any suitable function on the smart 
card desired by the issuer. In one embodiment, issuer 65 
application 112 may perform the functions of home banking 
or card content auditing, for example. 
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Provider application 114 is any suitable software appli- 
cation provided for a smart card by a business entity known 
as a provider. Applications can generally by classified as 
non-changeable applications that are loaded into ROM dur- 
ing the manufacturing stage and are not altered during the 
hfetime of the card, and changeable applications that can be 
loaded, installed or removed during initialization or post- 
issuance. Some applications may have components that 
reside in both immutable memory such as ROM and in 
mutable memory such as EEPROM. The present invention 
is suitable for use for any of a wide variety of types of 
provider applications. These types of applications include: 
loyally applications, stored value applications, credit/debit 
applications, transit, health care, insurance, electronic 
ticketing, electronic hotel check- in, and coupon applica- 
tions. 

FIG. 3 is another illustration of the Open Platform archi- 
tecture 10 of FIG. 2 suitable for explaining the present 
invention. As mentioned earlier, smart card operating system 
120 is any hardware dependent operating system for a 
particular smart card. Hardware independent API 122 is in 
communication with operating system 120 and provides a 
consistent API for smart card applications 112-116. API 122 
may be implemented using JAVA Card, Smart Card for 
Windows, and others. In general, APIs may be implemented 
using interpretative approaches (JAVA, BASIC, FORTH, 
etc.), compiled high level languages ("C") or native assem- 
bly coding. 

Applications 112-116 are present on the smart card and 
communicate directly with API 122 to perform functions on 
the smart card. In addition, applications 112-116 use Open 
Platform API 110 to access the unique system services 
provided by card manager 104 and any available security 
domains. As mentioned above, these services to the Open 
Platform architecture include application state tracking, per- 
sonalization support, card security management, etc. Secu- 
rity domains 106 and 108 also communicate with card 
manager 104. 

Life Cycles and Card Registry 

FIG. 4 illustrates the card manager life cycle state tran- 
sitions 200 according to one embodiment of the invention. 
This life cycle is illustrative of po.ssible states and transitions 
that work well with the pre.sent invention. Other life cycle 
states for the card manager and different transitions are also 
possible. As card manager 104 performs a supervisory role 
over the entire smart card, its life cycle can be thought of as 
being similar to the life cycle of the smart card. Card 
manager 104 owns and maintains the life cycle state infor- 
mation and manages requested state transitions in response 
to external commands (such as APDU commands). 

Pre-production state 202 refers to all smart card activities 
prior to the initial life cycle state of card manager 104, These 
activities include mounting a chip onto the smart card, 
loading an operating system onto the card, etc., and are 
specific to the manufacturer of the card, A wide variety of 
other activities may occur during pre-production state 202 
depending upon the card manufacturer, the type of card and 
the issuer. 

In general. Open Platform (OP) Ready state 204 and 
Initialized state 206 are intended for use during the pre- 
issuance phase of the smart card. States Secured 208, 
Ij^cked 210, and Terminated 212 are intended to be used 
during the post-issuance phase of the smart card. 

In Ready state 204 all of the basic functionality of 
run-time environment 102 is available and card manager 
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acting as the default application, is ready to receive, cation has taken place so that the application may execute, 
execute and respond to external APDU commands. In the The installation process does not include establishing the 
Ready state any files loaded into ROM are available, run- application as an externally visible application (the Select- 
time environment 102 is ready for execution, card manager able State), also, installation is not intended to personalize 
104 acts as the default application, and an initialization key 5 the application. Preferably, card manager 104 sets the life 
is available within the card manager 104. During this stale, ^y^.^^ application to the slate Installed during the 
security domains and their key sets may be loaded, appli- appUcalion installation process. 

cations from ROM may be installed, and applications may . . o 1 . ui -^-ivi • j . 1 i* - 

be loaded into EEPROM Selectable 224 is used to make an apphcalion 

llie Initialized State 206 is an administrative card pro- available to receive external commands (such as APDU 

duction state. Its definition is manufacturer and/or imple- '° commands) from outside the card. Card manager 104 is 

mentation dependent and may have a wide variety of defi- responsible for making an application ayailab e for selection 

Q^tjQQg by setlmg its life cycle state to Selectable. Preferably, 

TTie state Secured 208 Ls the normal operating slate for the applications are property installed and functional before they 

smart card after issuance. This state indicates that card of selectable, 

manager 104 should enforce the issuer's security policies for Transition to the Personalized state 226 is application 

post-issuance behavior such as application loading and dependent: preferably this state indicates that the application 

activation. These security policies may vary by card depend- has all of the necessary personalization data and keys for full 

ing upon the specific requirements of each card issuer. run-time functionality. The behavior of the application while 

Preferably, when an issuer determines that a card is ready to i° ihis state is determined by the application itself, and 

be issued to a cardholder, the issuer irreversibly sets the state preferably card manager 104 is not involved. Also, the 

of the card to Secured. In one embodiment, the card has the application manages its life cycle transition from the state 

following functionality in this slate: the card manager con- Selectable to the slate Personalized, 

tains its necessary key sets and security elements; issuer The definition of what is required for an application to 

initiated card content changes can be carried out through the ^5 transition to the state Blocked 228 is application dependent, 

card manager; post-issuance personalization of applications Preferably, a transition to this state indicates that an appH- 

belonging to the issuer can also be carried out by the card cation specific security problem has been detected either 

manager; security domains contain their necessary key sets from within the application or from outside the card, 

and security elements; provider initiated card content Preferably, the behavior of the application while in this state 

changes can be carried out by security domains that have the is determined by the application itself and card manager 104 

delegated management privilege; and post-issuance person- need not be involved. At any point in the application life 

alization of applications belonging to a provider can be cycle, card manager 104 may lake control for security 

carried out via a security domain. reasons and set the application life cycle state to Locked 

Card Manager (CM) Locked state 210 is used to tell card 230. Card manager 104 or an issuer uses the state Locked as 

manager 104 to temporarily disable all applications on the 35 a security management control to prevent the selection and 

card except for the card manager. This state provides the execution of an application. The card manager may set an 

issuer with the ability to detect security threats either inter- application to Locked if it detects a threat from within the 

nal or external to the card and to be able to temporarily card that appears to be associated with a particular applica- 

disable the functionality of the card. While in this state, the tion. Alternatively, an issuer may determine that a particular 

card will no longer function except via card manager 104 4Q application needs to be locked for a business or security 

which is controlled by the issuer. While in this state, there is reason and initiate the transition to the lojcked State via the 

an option to determine that the threat is cither no longer card manager. Once an application is set to Locked, only the 

present or is of limited severity such that the issuer can reset card manager may transition the application back to the state 

the card to the normal operating state of Secured. that it held just prior to being placed in the Locked Slate. 

Card manager 104 is set to the state Terminated 212 to 45 If an application is to be removed from the card either 
permanently disable all card functionality including card logically or physically, the card manager manages that 
manager 104. This state allows the issuer to logically destroy process and then sets the life cycle stale to Deleted 232. The 
the card if there is a severe security threat or if the card has request to delete an application may come from the appli- 
expired. Preferably, the Terminated state ts irreversible and cation itself, its associated security domain, the card man- 
indicates the end of the smart card life cycle. 50 ager or an issuer. If the card manager receives a request to 

FIG. 5 illustrates application life cycle state transitions delete an application which cannot be physically deleted 

220 according to one embodiment of the invention. The (e.g., because it is stored in ROM), the application may be 

application life cycle begins when an application is installed logically deleted by selling its stale to Logically Deleted, 

on a smart card. Installation may occur directly during Once an application is in the state logically Deleted, it 

loading or via another file present on the card. Card manager 55 cannot be reversed. The card manager considers this state to 

104 is responsible for managing the initial life cycle stale be the equivalent of physical deletion of the application, 

transition of an application before it is fully functional. Once Preferably, a security domain also follows the above 

an application is available for selection from the outside application life cycle. A security domain may have specific 

worid, it lakes control of managing its own life cycle. 'ITiese run-time behavior that is different from a regular application, 

life cycle states are ased to inform card manager 104 of the 60 Security domains are installed on the card by the card 

status of the application. The definition of these states are manager, which sets their slate to Installed. A security 

application dependent and are preferably known only to the domain is not available for selection while in this state. The 

application. Card manager 104 can take control of the card manager sets a security domain to the slate Selectable 

application life cycle if the card or the issuer detects a in order to enable personalization. Once a security domain 

security problem or if the application is to be deleted. 55 has been personalized with its keys and other necessary 

llie Installed State 222 means the application executable security elements, it sets its slate to Personalized, A security 

has been properly linked and any necessary memory alio- domain has the option to block itself as a protection mecha- 
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nism against a threat. Preferably, blocking a security domain 
does not have a required effect on access to that security 
domain by an application via Open Platform API 110. 
Security domains do, however, have the option to implement 
their own specific behavior while in the Blocked State. s 

As with any other application, the card manager may set 
a security domain to the state Locked and that domain may 
no longer be available for selection. Locking a security 
domain, however, does not have any effect on the access of 
that domain by applications via Open Platform API 110. A jo 
\jQckc6 security domain preferably Ls only unlocked via a 
command from the card manager. 

FIG. 6 illustrates a card registry database 250 according 
to one embodiment of the invention. Card registry 250 is 
persistent data storage on a smart card that supports various is 
functions of card manager 104 and may be implemented 
using any suitable medium and protocol. In one embodiment 
card registry 250 supports the functions of command 
dispatch, card content management, security management 
and the issuer's security domain in the card manager. 20 

Preferably, registry 250 includes one set of card manager 
data elements and a separate set of application data elements 
for each application on the card including security domains. 
Card manager AID 252 is a unique identifier for the card 
manager and is used in a Select command intended for the 25 
card manager. Card manager life cycle state 254 contains the 
current life cycle state of the card manager. Other data 
elements 256 may also be present. 

Application identifier 260 is a unique identifier for each 
application on the card and is used by the card manager for 30 
application selection. Application life cycle slate 262 con- 
tains the current life cycle slate of the application or security 
domain. Resource allocation 264 is a data element that 
contains a value for the total amount of resources that are 
available to an application. It is an application specific value 35 
and is used as a control mechanism by the card manager to 
limit the amount of resources that an application uses during 
run time. When additional resources are requested by an 
application. The card manager compares against this data 
element. Application privileges 266 are a set of data ele- 
ments that indicate privileges for each application. A variety 
of privileges may be indicated for an application: the appli- 
cation is a security domain without delegated management 
privilege; the application is a security domain with data 
authentication pattern privileges; the application is a security 
domain with delegated management privilege; the applica- 
tion has card manager locking privilege; the application has 
card termination privilege; the application is the default 
selected application; and the application has privilege to 
change a card global PIN. Each privilege may be marked as 50 
true or false, and an application may have more then one 
privilege marked as true. The card manager may apply a set 
of rules to these privileges for management of the card in 
any suitable fashion. 

Security Domain AID 268 is a data clement that contains ^5 
the AID of an application's corresponding security domain. 
When an application provider requests a connection to its 
security domain, the card manager uses this data element to 
return a reference to this appropriate domain. The card 
manager acts as the security domain for card issuer appli- 
cations if no other applicable security domain is present on 
the card. Other data elements 270 may also be present. 

Delegated Loading and Installation of an 
application 

'llie present invention provides a technique to extend the 
functionality of a security domain and to allow it to perform 
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delegated management of smart card applications. For 
example, the present invention allows a security domain to 
perform delegated loading, installation and/or deletion of an 
application. By delegating this management to their security 
domain, a provider of an application is assured of more 
direct control and management of their application, yet an 
issuer still maintains some control over the management of 
the card. 

The Open Platform architecture allows parties other than 
the card issuer such as application providers to load, install, 
and delete their own applications. In general, these processes 
are referred to as delegated management. In general it is 
desirable that a card i.ssuer have complete control over the 
smart cards it issues. The card issuer, however, may not 
necessarily wish to manage all card content changes, espe- 
cially when the content does not belong to the card issuer but 
to an application provider. This concept of delegated man- 
agement is incorporated into the Open Platform architecture 
to allow the card issuer the option of empowering applica- 
tion providers to initiate changes to the issuer's smart cards 
that are pre-approved by the card issuer. 

This pre-approval ensures that only card content changes 
that the card issuer has approved will be accepted and 
processed by card manager 104 of a smart card. This 
delegation of control in the card update process allows 
application providers more flexibility in managing their own 
applications on the card issuer's cards. 

Delegated loading allows the application provider to 
establish a loading session for transferring their application 
files directly to their own security domains. Once each 
APDU command has been securely transferred onto the 
card, the security domain passes it to the card manager for 
loading into persistent memory. The card manager is able to 
identify the authenticity of these processes through the use 
of a data authentication pattern applied to the install com- 
mands and the load file itself. The card manager does not 
verify the data authentication patterns applied to individual 
Load commands. The command related DAPs which the 
card manager does check are referred to as the Load and 
Install tokens. 

In addition to these DAPs which are intended for the card 
manager, the application provider applies DAPs (which 
cover the command and tickets) for securing (integrity) the 
transport of all commands (Install and Load) to a security 
domain. Using this terminology, a token is a DAP intended 
for the card manager, which is distinct from the DAPs that 
are applied and intended for a security domain. 

'Ilie card issuer pre-authorizes the initial install command 
(which performs loading) and the load file through the use 
of these data authentication patterns. The data authentication 
pattern for the application file is included in the initial Install 
command to ensure that application which has been 
approved by the card issuer is the same application that is 
subsequently received by the card manager through the 
scries of loading commands that follow the first install 
command. 

A delegated installation process is used to install an 
application that is already present in the card. The card issuer 
pre-authorizes a second install command that includes the 
application installation information. Once again a data 
authentication pattern is appended to this command to 
ensure its authenticity. Once the card manager has validated 
the install command and carried out instmcted operations, 
the card manager may generate a response to return to the 
security domain. Completion of a delegated load results in 
the generation of a load receipt while completion of a 
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delegated installation results in the generation of an install ware and security domains, and the keys of at least one 

receipt. The processes in the delegated loading and del- security domain are kept secret from the issuer, 

egated installation may occur in a single transaction where a group of keys associated with a particular security 

an application is loaded and installed immediately. domain is referred to as a key set and is uniquely identified 

Alteraatively, the delegated loading and mstallation pro- 5 by a key set identifier Each key within a key set is also 

cesses may occur independenily of one another Preferably ^ -j^^^i^^^ ^ ^ ^ idcnlifitT. These keys in a key 

for delegated loadmg and installation, the card manager is in ^^^^^ ^ ^.^^ ^^^^.^^ 

the life cycle state Secured, the secunty domain to be used ^^^^ .^^ .^^^^^^ authentication, confidentiality, 

IS in the state Personalized, and the secunty domain has the .^^^^ ^ encryption. Uter. the smart card is issued 

delegated management privilege. ^ cardholder and becomes activated in step 306. At this 

A secunty domain may be loaded onto a smart card and in time the card is in its secured state 208 and the 

be provided with cryptographic keys in a wide variety of cardholder is using the card. 

manners. One difficulty with the prior art is that if a security • . • r ^ j • 

. . ,/ 1 J J . J ; At some pouit in time, an application provider may desire 

domain or other application were loaded onto a card post- . i- r fu j j 1 . .1. 

• *u . •/ 1 J 1 1 J . lo wnte a new application for the card and place it onto the 

issuance, is that it would rely upon keys on the card that 15 , . . . , , » ^ 1 j- a a 

1 ' , . ^ I -J T^- 1- card post-issuance usmg delegated loading. A provider 

were known to an issuer or another provider This reliance , / , ... . , * .1. . 1 c 

-J c .if 1 J- r . would choose this option to ensure that the secret keys of a 

upon an issuer or other provider for the loadmg of a secunty , • j * u -i i_i . *i_ _* 

. ... • .1. . 1 • L - .1. . security domain do not become available to another party, 

domain might compromise the secret keys within that . , n . . • . -j^n 

. . 1 1. Accordingly, as a first step, a provider in step 310 writes a 

domain; a provider would wish that those keys were kept . , \ , . i_i 1 . 

J . r . • J suitable smart card application in any suitable language such 

separate and secret from an issuer or other provider Two -in ia^/a 11^ • a li / ur^T, 7 i 

... . . J . J . as JAVA, Visual Basic, Assembly language. C , etc. In a 

techniques have been used to provide a security domain on ^ , . / . c \ r\ 

j\ . . , *u . J * u 1 * preferred embodiment, this appucation conforms to Open 

a card hav.ng secret keys ha. do not become known to an ^^^^J^^ independent API 122. 

issuer or other provider. In one example, any number of - . , . . 

security domains with their included secret keys are installed ^'^P °^ '^e security domains on the card is 

onto the smart card by a manufacturer when the card is ,5 «^ig°«d '° aPP^cation provider. The provider may be 

produced. These domains are known only to the manufac- ^^'S^^^ * ^«="fi'y ^"^^^ fr"" manufacturer who has 

turer. When the card is released to an issuer, the manufac- ^ept a number of security domains m escrow from the time 

turer may release certain sets of the keys to the issuer while °^ '^ard manufacture, or the provider may be aUowed to load 

keeping secret key sets pertaining to various other of the * ^""'y d"™^"" conjunction with a trusted third 

security domains. These retained key sets are either held by 30 P"'y- conjunction with being assigned a secunty domam, 

the manufacturer, put in escrow or given to a trusted third *'«P ""e application provider receives the secret key 

party. Later in the life of a card when a new application corresponding to this security domain. These keys may 

provider wishes to take ownership of a security domain on ''f « "^^n ^eld in escrow by the card raanufacmrer on behalf 

the card and use it to load an application, this provider °^ °^ ^^^^ ™ay ^ dynamically created by 

receives a secret key set for one of the unassigned security 35 application provider and loading onto the card along 

domains from the trusted third party. In this way, the key set ^'''^ " ^""'y 'I"'"*'" 'he help of a trusted 

for a security domain is known only to the new application '^ird party. Because the trusted third parly has ownership of 

provider and is kept separate from the issuer or another ^ security domain and its keys, it can assist the application 

application provider provider m loading a new security domain with its new keys. 

In another example of how a security domain and its 40 ^'^"^ either technique, the application provider receives 

secret keys may be assigned to a provider, a technique as ^^^^^hip of a security domam on the smart card and its 

described in U.S. patent application Scr No. 09/046,993 ^'^^ ""^J^^ '''' 

may be used. In this scenario, one of the security domains on ' party. 

the card is assigned to a trusted third parly. The tnisted third step 322 the issuer approves the application through a 
party takes ownership of the domain and control of its secret 45 suitable arrangement with the application provider; this step 
keys. Once the card is issued and is in use by a cardholder, ^ descnbed m further detail in FIG. 7B. Through this step, 
the trusted third party retains ownership of the security ^^e smart card onto which the application will be loaded 
domain. A new application provider that wishes to load an becomes assured that the issuer has checked and approved of 
application onto the card would then approach the trusted *he application. It allows the issuer to keep a certain amount 
third party for permission to use their security domain. The 50 ^^^^^^^ delegated loading process, 
application provider would then load their own application In step 326 a cardholder inserts the smart card into any 
(which might be a new security domain) using the security suitable card acceptance device. This insertion may be part 
domain and secret keys of the trusted third party. In this of a regular transaction for the cardholder or it may be a 
fashion, a new application provider is allowed to load a new special transaction solely for the purpose of downloading the 
application and security keys without having to share the 55 provider application. In step 330 the provider down- 
same with an issuer or another application provider. These loads the new application onto the smart card in the card 
tecliniques and others may be used to provide a security acceptance device; this step will be described in further 
domain on a smart card having a security key set that is detail in FIG. 70. In this fashion, the loading of the 
known to the application provider to whom the security application has been delegated to an application provider 
domain belongs. 60 In step 334 the provider installs the application that has 
FIG. 7 A is a flow diagram describing a technique for been loaded onto the smart card; this step will be described 
performing delegated loading. As mentioned above, there in further detail in FIG. 7D. Additionally, the provider may 
are a variety of ways that a security domain may be present perform other functions for the application such as person- 
on a smart card and its secret keys provided to an application alization. At this point, delegated loading and installation of 
provider without the issuer or other application providers 65 an application onto the card has been performed, 
being involved. Step 302 refers to this process by which a FIG. 7B is a flow diagram that describes how an issuer 
smart card is manufactured, installed with operating soft- approves an application for delegated loading and installa- 
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tion. Once an application provider has written an application if the application has not been changed, the newly created 

for a smart card and desires to load that application onto an DAP should match the received DAP. 

issuer's smart cards via the delegated loading process of the ^ext, in step 344 the issuer determines general charac- 

present invention it provides the application to the issuer for j^^istics of the application to send along with the application 

approval. It should also be noted that the provider may also 5 code in a secure manner. These general characteristics of an 

give the apphcation to a trusted third party for approval. In 3 j^^i^je ,he name of the application (or its 

slep 340 the issuer pertorms testing 01 the application given , ^ .-a c • j 

, r, . ™°. p „ appUcations identifier), an identifier for the sccunty domain 

to it by the apphcation provider. Testing of an apphcation for ...... ,- . . • .1. • 

\ i_ _c J- c • * f to which the apphcation has been assigned by the issuer, the 

a smart card may be performed in any or a variety 01 ways ,. - / . 

, j. j-.u * j 11* 1 memory hm nations of the apphcation, and any privileges 

and IS a step understood in the art, and generally involves ^ .u * i- *• • *i. j 

functional tests (optional) and security Tests (mandatory). apphcaUon may require on the card. 

Testing of the application involves checking its operational ^he memory requirements of an apphcation mclude how 

behavior on a smart card, checking its operational memory ^^^^ persistent memory an application requires for storage 

requirements, etc., ensuring that the application is secure, ^"^ ^^w much RAM il requires during execution. Privileges 

and checking for viruses and card related threats. Once the .5 application include whether or not the application can 

issuer (or trusted third party) has tested the apphcation and ^^^^^ whether the apphcation can lock the card 

it to ensure that it behaves correctly, the application is manager, whether the application can change the card global 

"certified" and the issuer is ready to prepare the application ™* and others. If the application to be loaded in a delegated 

for a delegated load and installation by the provider. fashion is a security domain, the privHeges granted to the 

In step 342 creation of a data authentication pattern 20 T""'^^ f^'^'u '"''^''^^ °' "^"^'''l 

(DAP) may be performed in a variety of ways. In general a ^\ delegated management privilege and 

data authentication pattern is a sequence of bytes unique to ^^ether or not the security domain has the capability to 

a string of data such as a command or an application. By ^^"^y authentication patterns from other applications 

calculating a DAP for an application (for example) and ^^^^^^ ^ delegated fashion. 

delivering the DAP with the application, an entity such as a 25 ^^^P ^ command is assembled for loading the 
smart card can recalculate the DAP using the same crypto- apphcation onto the smart card. This load command includes 
graphic technique. By next comparing the received DAP to ^^e application characteristics determined in step 344 and 
the newly calculated DAP the smart card can verify the may include other information particular to the type of 
integrity of the received command or application. command protocol being used. Preferably, this load corn- 
Creation of a DAP may be done in conjunction with either 30 "'^"'^ appended to il the data authentication pattern 
symmetric or asymmetric cryptography, or other suitable ^-^^^^^^ ^^e apphcation in step 342. By combining the 
technique. In conjunction with symmetric cryptography, the P^"^™ application, it is ensured that the apphcaUon 
information to be verified (such as a load command, and ^^^^^^^^ approved by the issuer is the same file that will 
install command, an apphcation, or a load file) is first subsequently be received by the card manager on the card, 
assembled. Next, a function such as SHA-1 or MD5 is 35 ^ exemplary load command is shown m FIG. 8. 
applied to the information to produce a hash (a unique In step 348 a data authentication pattern is created for the 
sequence). Next, a symmetric key is applied to the hash to load command generated in step 346. It will be appreciated 
encrypt it. This unique encrypted sequence is referred to as t^at generation of this pattern for the entire load command 
the data authentication pattern (DAP). In one embodiment, may be performed in many ways. In a preferred embodiment 
a message authentication code (MAC) may be used to 40 invention, the pattern for the load command is 
implement a DAP. The DAP may then be appended to the calculated for the entire load command including the general 
clear text of the information for transmission. On the receiv- characteristics it contains as well as the data authentication 
ing end (for example inside the smart card), the apphcation pattern for the application. Preferably, a load command 
(for example) and its appended DAP are received. Next, the calculation key known only to the issuer is used to calculate 
same technique is applied to the application using the same 45 this data authentication pattern of step 348. In one embodi- 
cryptographic algorithm as before to produce a new DAP for "lent of the invention, this load command may appear as 
the application. Assuming the application has not been shown in FIG. 8 and is based upon a standard APDU 
changed enroute, the newly created DAP should match the command under ISO 7816-4. 

DAP received appended to the application. A difference in Step 350 determines the installation behavior of the 

the two DAPs will indicate that the integrity of the appli- 50 application. The information determined in the step provides 

cation has been compromised. instructions for the card on what to do with an apphcation 

In a preferred embodiment of the invention, asymmetric when it is installed. This information allows the card to 

cryptography is used to produce a data authentication pattern correctly install an apphcation on the card that has previ- 

for either of the commands or for the application itself. For ously been loaded onto the card. For example, this infor- 

example, public key/private key cryptography may be used 55 mation includes the life cycle state in which the apphcation 

to provide a unique data authentication pattern that the smart should be when installed on the card, instructions for install- 

card may verify. In this example, the issuer maintains a ing the application, and other information, 

public key/private key pair. The private key is used by the In step 352 a command is created for installation of the 

issuer when approving the application; i.e., the issuer creates application on the card and includes the information dctcr- 

data authentication patterns for the commands and for the 60 mined in step 350. Preferably, this installation command 

application. The private key is used to sign a cryptographic does not include the data authentication pattern for the 

hash of the command or the application which then becomes application, although it may. In step 354, a data authentica- 

the unique data authentication pattern. The issuer's pubhc tion pattern of the entire install command created in step 352 

key held by the card manager is used to verify the data is appended to the end of the install command. Preferably, an 

authentication pattern received along with either a command 65 install command calculation key known only to the issuer is 

or an apphcation. 'Iliat is, the smart card uses the issuer's used to create this data authentication pattern. In one 

public key to verify the DAP for the application. As above, embodiment of the invention, this install command with its 
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appended data authentication pattern may appear as shown approved by the installer, the installer sends an approval 

in FIG. 9 and may be implemented using the APDU Install message back through the card manager and security domain 

command under the ISO 7816-4 protocol. to host computer 602. Upon receiving the approval message. 

In step 356 the assembled load and install commands computer is alerted that loading of the application 

(along with their data authentication patterns) and the tested 5 has been approved. 

and certified application (along with its data authentication Accordingly, in step 374 the host sends the apphcat.on to 

pattern) are delivered to the application provider. The appli- ^""'J domam 106 oyer hcks 620. Preferably, mcluded 

cation provider is now enabled to perform either the del- ^'^ "PP'-^'ion is he data aulhent.cat.on pattern pre- 

.... J , . J • * 11 L *u c viously created for it by the issuer. In a preferred 

egated load or a delegated installation Tlirough the use of ,^bo/in,ent, the appHcation is embedded within a load file 
the data authentication pattern, not only are the application 30 ^^^^ ^ Ulustrated in FIG. 10 which itself is part of an 

and the commands locked (e.g., a change in one of them y^jj^U Load command. Of course, the appHcation may be 

would be detected), but the identity of the issuer and its embodied in other types of commands, need not necessarily 

approval of the application is supplied via the secret issuer be part of a load file, or simply may be transmitted by itself 

keys used to calculate the data authentication pattern for the along with it data authentication pattern. As with the load 
application and the load and install commands. In this ^5 command, in step 376 the security domain passes the 

fashion, even though a party other then the issuer is allowed application on to the card manager. In step 378 the card 

to load or install an application, the smart card will recog- manager authenticates the application by verifying its data 

nizc that it is authorized to load or install the application by authentication pattern that was created by the issuer prcvi- 

verifying the data authentication patterns that have been ously. As mentioned above, the card manager may auihen- 
created. Such use will now be described. 20 ticate the data authentication pattern of the application using 

FIG. 7C is a flow diagram describing one embodiment of ^.^V ?^ » ^^.^'y °^ cryptographic techniques. If any authen- 

the download apphcation step of FIG. 7A. In step 360 a data ^^i^' "«= °ng"Ml ^^^°^y contents are restored, 

link is estabUshed between host computer 602 and smart . ^'''P the lastaller loads the actual application code 

card 604 while the card is in a card acceptance device. '"to memory of the smart card and performs hnkmg to any 

D™f^,.uu, o .„fh-„t-^o*;^„ 25 run-time libraries and Other necessary steps. As mentioned 

Preferably, as part of this procedure, a mutual authentication , r j u j- . .u ■ . n c 

/ *: , i.uL. above, in a preferred embodiment, the installer performs a 

process is performed between the card and the host using a ^^^^ ^ processing one or more APDU Load commands that 

key set provided to the application provider by the issuer or ^^^^^-^ application. Assuming that loading and linking 

other trusted third party (as previously described). performed successfiiUy, in step 384 a confirmation 

Preferably, the security domam keys provided to the appli- ^ ^^^^ ^^^^ -^^^^^^^ -^^^ ^^^^ computer 

cation provider are so as to assure secunty domam 106 ^^^2 via the card manager and the security domain. Once host 

that the mconiing information ^ coming from an authorized has received the confirmation, it is notified that the 

source are only seen by the application provider. In step 362 ^ u^alion has been loaded successfully, 

host 602 sends load command 500 to secunty domain 106 , ... ^ r , -jqa .u « 

AnTAii • . T .u- • .c In ouc embodiment of stcp 384, ihc Confirmation message 

using APDU mterface 610. In essence, this is a request for . , r i j • . i j • . j 

a load of an a lication takes the form of a load receipt. TTie load receipt provides 

* confirmation from the card that a successful load of the 

Once the security domain has received the load command, application has occurred through the delegated loading 

in step 364 it passes the command to card manager 104. process. Preferable, the load receipt includes unique data 

Because this command is coming from a security domain, related to the delegated loading transaction and a data 

the card manager knows that the load command is pan of a authentication pattern applied by the card manager. By 

delegated load process. having the card manager apply the data authentication 

In step 366 the card manager authenticates the load pattern using a key known only to the issuer, the issuer can 

command. Preferably, the card manager uses the same be assured upon later receipt of the load receipt that in fact 

cryptographic technique used by the issuer to create load the delegated load of the application was performed suc- 
command DAP 514 to verify the load command DAP on its 45 cessfully. In one embodiment, the load receipt is returned in 

own. The card manager then compares its created pattern the data field of the response message from the last APDU 

with pattem 514 included with the load command in order load command sent to the security domain, 

to authenticate that the load command received from the Construction of a load receipt and calculation of a data 

application provider is the same load command that had authentication pattem may be performed in a variety of 
been previously created and approved by the issuer. As 50 ways. By way of example, the data authentication pattern is 

described above, creation of load command DAP 514 may calculated using data unique to the loading transaction and 

be done using a variety of cryptographic techniques and a card manager load receipt calculation key known only to 

using either asymmetric or symmetric cryptography. the issuer. Preferably, the card manager calculates ihe data 

In step 368 the card manager passes the authenticated load authentication pattern and con.structs the load receipt. Infor- 
coramand to install routine 614 which process the load 55 mation upon which the data authentication pattem is calcu- 

command. Preferably, processing of the load command is lated using the key may include: a confirmation counter 

performed as is normally done for a first APDU Install (which is used to indicate the number of times an apphcation 

command that has been received from an issuer. In other has been loaded on a single card), card unique data (such as 

words, the installer is unaware that the load command is part a unique card identifier), the load file AID, and the security 
of a delegated load operation and process the command as 60 domain AID. The load receipt key is then applied to this 

if it were loading an application received directly from the information to generate the load receipt data authentication 

issuer. In general, this processing checks to see if an instal- pattern. The load receipt is then constructed by concatenat- 

lation of the application can be allowed. For example, the ing the load receipt DAP with the confirmation counter and 

process checks whether the application is already installed, identification data for the card. In this fashion a provider 
whether there is memory available, whether the needed 65 may later provide the load receipt to the issuer to confirm 

libraries are present, whether the right version of the oper- that the provider's application was successfully loaded onto 

ating system or mntime environment is present, etc. Once a particular smart card. 
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FIG. 7D is a flow diagram describing the install applica- 
tion step of FIG. 7A, In step 386, host 602 sends install 
command 520 to security domain 106 using APDU interface 
610. In essence, this is a request for an install of an 
application. Preferably, the security domain keys provided to 5 
the application provider previously by the issuer are used so 
as to assure security domain 106 that the incoming infor- 
mation is coming from an authorized source. 

Once the security domain has received the install 
command, in step 388 it passes the command to card 
manager 104. Because this command is coming from a 
security domain and not from an issuer off-card, the card 
manager knows that the install command is part of a 
delegated install process. 

In step 390 the card manager authenticates the install 
command. Preferably, the card manager uses the same 
cryptographic technique used by the application provider to 
create install command DAP 534 to recreate the install 
command DAP on its own. ITie card manager then verifies 
the signature pattern included with the install command in 
order to authenticate that the install command received from 
the application provider is the same install command that 
had been previously created and approved by the issuer. As 
described above, creation of install command DAP 534 may 
be done using a variety of cryptographic techniques and 
using either asymmetric or symmetric cryptography. 

In step 392 the card manager passes the authenticated 
install command to the install routine 614 which processes 
the install command. In step 394 the installer process the 
install command which instructs the card to take certain 
actions with respect to the application recently loaded. These 
actions may include but are not limited to allocating data 
space, placing the application into an initial state and setting 
additional privileges such as default selection and making 
the application available for selection. 

Preferably, processing of the install command is per- 
formed as is normally done for a second APDU Install 
command that has been received from an issuer. In other 
words, the installer is unaware that the install command is 
part of a delegated install operation and process the com- 
mand as if it were installing an application at the direction 
of the issuer. 

In step 396 a confirmation message is sent back to the 


the issuer. Preferably, the card manager calculates the data 
authentication pattern and constructs the install receipt. 
Information upon which the data authentication pattern is 
calculated using the key may include: a confirmation 
counter, card unique data (such as a unique card identifier), 
the load file AID, and the application instance AID. The 
install receipt key is then applied to this information to 
generate the install receipt data authentication pattern. The 
install receipt is then constructed by concatenating the install 
receipt DAP with the confirmation counter and identification 
data for the card. In this fashion a provider may later provide 
the install receipt to the issuer to confirm that the provider's 
application was successfully installed onto a particular smart 
card. 

FIGS. 8 and 9 illustrates examples of a load and an install 
command that may be created in steps 346 and 352 of FIG. 
7B. Those of skill in the art will appreciate that these 
commands may take any of a variety of forms and may have 
fields that occur in different orders. In a preferred embodi- 
ment of the invention, these commands are implemented 
according to the APDU protocol such as described in the 
'^Open Platform Card Specification'' referred to above. 
Install 502 indicates that this is an APDU Install command. 
This command may be used to cither load an application or 
install an application. A load indicator 504 indicates that a 
load file containing an application is to be loaded. A load file 
application identifier 506 contains a unique identifier for the 
application contained in the load file. A security domain 
application identifier 508 indicates to which security domain 
the application to be loaded belongs. Load parameters 510 
specify additional information that may be required by the 
card to load the application. These parameters may include 
any of the application general characteristics determined in 
step 344. A data authentication pattern 512 for the load file 
uniquely identifies the load file and/or the application and 
may be created as described in step 342. The data authen- 
tication pattern 514 for the entire load command 500 may be 
created as described in step 348, 

Install 522 indicates that this is an APDU Install com- 
40 mand. An install indicator 524 indicates that an application 
is to be installed. A load file application identifier 526 
contains a unique identifier for the application contained in 
the load file. An application identifier 528 in the load file 
identifies a particular application in the load file since one 


35 


provider host via the card manager and security domain in 45 load file may contain multiple applications. An apphcation 


much the same way as in step 384. 

In one embodiment of the invention, the confirmation 
message of step 396 takes the form of an install receipt that 
may be produced in the same fashion as the load receipt of 
step 384. The install receipt provides confirmation from the 
card that a successful installation of the application has 
occurred through the delegated installation process. 
Preferable, the install receipt includes unique data related to 
the delegated installing transaction and a data authentication 


instance identifier 530 specifics the identifier which will be 
established for selection of the newly installed application. 

Install parameters 532 specify additional information that 
may be required by the card to install the application. These 
50 parameters may include any of the application installation 
behavior determined in step 350, The data authentication 
pattern 534 for the entire install command 520 may be 
created as described in step 354. 

FIG. 10 illustrates a load file 560 containing an applica- 


pattern applied by the card manager. By having the card 55 tion according to one embodiment of the invention. It should 


manager apply the data authentication pattern using a key 
known only to the issuer, the issuer can be assured upon later 
receipt of the install receipt that in fact the delegated install 
of the application was performed successfully. In one 


be appreciated that an application to be loaded onto a card 
may be embedded within a load file, as shown, may be 
loaded simply by itself, or may be loaded in combination 
with other applications and information. In a preferred 


embodiment, the install receipt is returned in the data field 60 embodiment of the invention, an application is embedded 


of the response message from the last APDU Install com- 
mand sent to the security domain. 

Construction of an install receipt and calculation of a data 
authentication pattern may be performed in a variety of 


within a load file using tag-length-value format. Load file 
560 includes any number of data authentication pattern 
(DAP) blocks 562 followed by a data block 564 which 
includes the application. There may be multiple DAP blocks 


ways. By way of example, the data authentication pattern is 65 562 that precede a data block 564. Each DAP block would 
calculated using data unique to the installing transaction and correspond to a different entity that wishes to review and 
a card manager install receipt calculation key known only to certify the application before it is allowed to be loaded onto 
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a smart card. For example, even though an issuer may wish 
to provide its own DAP block for an application, there may 
be a regulatory agency that also wishes to review and certify 
the application and add its own data authentication pattern 
for the application. In this way, multiple entities can approve 5 
an application to be loaded onto a smart card. During the 
loading or installation process, the card manager or a secu- 
rity domain which represents an entity can verify that the 
data authentication pattern earlier added by that entity has 
not changed. It is also conceivable that there is no DAP 
block 562 present with an application. In this scenario, a data 
authentication pattern may still be calculated for the appli- 
cation iLself but need not appear in a formal DAP block. 7'he 
data authentication pattern for the application may then be 
directly appended to the application itself, or may appear in 
an install command. ^5 

In one embodiment of the invention, an application is 
embedded within a load file 560 as illustrated in FIG. 10. In 
this embodiment, any number of DAP blocks 562 precedes 
a data block 564 which are each structured in tag-length - 
value format. A load file is the physical data file that is 20 
transferred to a smart card in order to make changes to the 
card contents. In other words, one or more DAP blocks may 
be used for the integrity verification of the application. 

DAP block 562 includes identification information as well 
as the related authentication pattern. Tag 566 indicate that 25 
what follows is a DAP block. Length 568 indicates the 
length of the DAP block value to follow. The DAP block 
value 570 includes identification information and the value 
of the authentication pattern. An identifier tag indicates that 
an identifier is to follow. An identifier length indicates the 20 
length of the identifier, and an identifier value identifies the 
entity associated with DAP block 562 that has provided the 
authentication pattern for the following data block 564. 
Next, within value 570 a DAP tag indicates that an authen- 
tication pattern is to follow. A DAP length indicates the 35 
length of the pattern and finally a DAP value provides the 
actual data authentication pattern providing integrity verifi- 
cation for the application. 

Data block 564 includes a data block tag 572 indicating 
that a data value (an application) is to follow. Data block 40 
length 574 indicates the length of the following value. Data 
block value 576 includes the application to be loaded. Value 
576 may contain one or more applications and/or any 
combinations of library and support files. 

In one specific embodiment of the invention, tag 566 has 45 
as value of *E2', DAP identifier tag and DAP tag of 570 have 
values of *4F' and *C3', respectively, and tag 572 has a value 
of 'C4\ Also, DAP block 562 is optional. Even if present, 
DAP block length 568 may be set to *00\ 

A load file may be transported onto the card either via card 50 
manager 104 or a security domain that has the delegated 
management privilege. Card manager 104 preferable is 
responsible for the physical memory management and life 
cycle management of a load file. A load file may have two 
life cycle states which are "Loaded" and "Logically 55 
Deleted." All load files present on the card and available for 
use are in the Loaded state. Any load file which has been 
requested to be deleted by the card manager or a security 
domain but cannot be physically deleted is in the state 
Logically Deleted and cannot be accessed. Loading an 60 
application involves first loading the load file onto the card, 
and then extracting the application and installing it. 
Alternatively, the load file is processed dynamically during 
the loading transaction during which the application is 
extracted. In this alternative embodiment, the remainder of 65 
the load file is disregarded and the load file never exists on 
the card. 


,632 B2 

22 

FIG. 11 illustrates an embodiment in which an application 
may be downloaded from an application provider host 
computer 602 to a smart card 604 in a delegated manner. 
Host computer 602 is any suitable computing device under 
control of an application provider that includes the load 
command 500, load file 560 and install command 520 that 
have been approved and received from the issuer. 

Smart card 604 includes card manager 104, security 
domain 106 and other typical features of a smart card (not 
shown). Security domain 106 and card manager 104 each 
include an APDU interface, 610 and 612 respectfully, that 
allow an outside entity to communicate with them. 
Additionally, card manager 104 includes an installer routine 
614. Installer 614 is a known low-level memory manage- 
ment routine that accepts application code and other infor- 
mation and writes it to memory. 

In the prior art, an issuer by virtue of its secret keys would 
be able to talk directly to card manager 104 through APDU 
interface 612 to provide an application to be loaded onto the 
card. Installer 614 would accept this application via the card 
manager and install the application in the memory of the 
smart card. For security, the keys to access card manager 104 
would not be accessible to parties other then the issuer, 
meaning that only an issuer could download an application. 
Through use of the present invention, a third party applica- 
tion provider is able to perform a delegated load of an 
application via security domain 106, Using keys previously 
received under an arrangement with an issuer, host computer 
602 establishes a secure communication channel 620 to 
security domain 106 of smart card 104 in any suitable card 
acceptance device (not shown). 

Security domain 106 then manages the downloading of 
load command 500, load file 560 and install command 520 
onto smart card 604. In this fashion, these commands and the 
load file may then be delivered via an internal link 622 to 
card manager 104 using a delegated management interface 
616. The card manager then passes the commands and load 
file to installer 614 for loading and installing an application 
onto a smart card. Installer 614 receives and process these 
commands from security domain 106 in much the same way 
as if these command had been received from an issuer via 
card manager 104. Further, the data authentication pattern 
present in the commands and in the application may be 
checked by the card manager to ensure the authenticity and 
integrity of the information as established by the issuer. 
Further details on loading and installation are provided in 
FIG. 7C. 

Delegated Deletion of an Application 

Application providers have the ability to instmct the card 
manager to delete applications that they own. The card 
manager will honor these requests without authorization 
from the card issuer. Therefore, there is no requirement for 
a delete token for to be included with a Delete command 
passed from an application provider's security domain to the 
card manager. Once a Delete command is received by the 
card manager, the card manager verifies that the application 
being requested for deletion belongs to the security domain 
that issued the command. After verifying this information, 
the card manager carries out the deletion and then returns a 
response that includes a DAP generated by the card manager, 
lliis response including the DAP is referred to as the Delete 
Receipt. FIG. 12 is a flow diagram describing a technique for 
performing delegated loading. 

In a preferred embodiment of the invention, a card under- 
going a deletion is in a particular state. For example, the card 
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manager life cycle state is Secured, the security domain to 
be used is in the state Personalized and has the delegated 
management privilege. Preferably, the APDU sequence used 
is first a Select command indicating a security domain, then 
an optional authentication process, followed by a Delete 
command referencing a particular application identifier 
(AID). 

In one embodiment, the card manager uses the following 
techniques for application removal. Application removal 
may involve the removal of application instance as well as 
the associated Load file. Physical removal may occur in 
mutable persistent memory while only logical removal is 
possible in immutable, persistent memory. For applications 
instances or Load files loaded into mutable persistent 
memory, the card manager: deletes the identified application 
instance or Load File from mutable persistent memory; 
reclaims the mutable persistent memory space for future use; 
and removes the AID of the removed application or Load file 
from the card registry. For application instances or Load files 
loaded into immutable persistent memory, the card manager: 
deletes related application data space (if any) contained in 
mutable persistent memory; and changes the life cycle state 
of the deleted application and/or Load file(s) in the card 
registry from the current state to Logically Deleted. 

Alternative Embodiments 

In an alternative embodiment, the delegation mechanism 
mentioned above may be used to allow the issuer to out- 
source loading and management functions potentially to a 
single (or multiple) party who can then represent the issuer 
to other application providers in the event that an application 
provider does want the issuer (or his representative) to load 
the application provider's application. For example, a first 
service provider is the owner of one security domain on a 
card and a second service provider is the owner of another 
security domain on the card. The card issuer has a contract 
with the first service provider for delegated loading and a 
contract with the second service provider, but not for load- 
ing. The application provider has a contract with the second 
service provider for application personalization. At the 
request of the application provider, the first service provider 
loads the application (using the first security domain) and 
the second service provider personalizes the application 
(using the second security domain). The provider is then 
allowed to use the application on the card. 

Computer System Embodiment 

FIGS. 13 and 14 illustrate a computer system 900 suitable 
for implementing embodiments of the present invention, 
such as any of the computers used in the systems shown in 
FIG. 1. FIG. 13 shows one possible physical form of the 
computer system. Of course, the computer system may have 
many physical forms ranging from an integrated circuit, a 
printed circuit board and a small handheld device up to a 
huge super computer. Computer system 900 includes a 
monitor 902, a display 904, housing 906, a disk drive 908, 
a keyboard 910 and a mouse 912, Disk 914 is a computer- 
readable medium used to transfer data to and from computer 
system 900. 

FIG. 14 is an example of a block diagram for computer 
system 900. Attached to system bus 920 are a wide variety 
of subsystems. Processor(s) 922 (also referred to as central 
processing units, or CPUs) are coupled to storage devices 
including memory 924. Memory 924 includes random 
access memory (RAM) and read-only memory (ROM). As 
is well known in the art, ROM acts to transfer data and 
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instructions uni-directionally to the CPU and RAM is used 
typically to transfer data and instructions in a bi-directional 
manner. Both of these types of memories may include any 
suitable of the computer- readable media described below. A 

5 fixed disk 926 is also coupled bi-directionally to CPU 922; 
it provides additional data storage capacity and may also 
include any of the computer-readable media described 
below. Fixed disk 926 may be used to store programs, data 
and the like and is typically a secondary storage medium 
(such as a hard disk) that is slower than primary storage. It 
will be appreciated that the information retained within fixed 
disk 926, may, in appropriate cases, be incorporated in 
standard fashion as virtual memory in memory 924. Remov- 
able disk 914 may take the form of any of the computer- 
readable media described below. 

CPU 922 is also coupled to a variety of input/output 
devices such as display 904, keyboard 910, mouse 912 and 
speakers 930. In general, an input/output device may be any 
of: video displays, track balls, mice, keyboards, 
microphones, touch-sensitive displays, transducer card 
readers, magnetic or paper tape readers, tablets, styluses, 
voice or handwriting recognizers, biometrics readers, or 
other computers. CPU 922 optionally may be coupled to 
another computer or telecommunications network using 
network interface 940. With such a network interface, it is 
contemplated that the CPU might receive information from 
the network, or might output information to the network in 
the course of performing the above-described method steps. 
Furthermore, method embodiments of the present invention 
may execute solely upon CPU 922 or may execute over a 
network such as the Internet in conjunction with a remote 
CPU that shares a portion of the processing. 

In addition, embodiments of the present invention further 
relate to computer storage products with a computer- 

35 readable medium that have computer code thereon for 
performing. various computer- implemented operations. The 
media and computer code may be those specially designed 
and constructed for the purposes of the present invention, or 
they may be of the kind well known and available to those 
having skill in the computer software arts. Examples of 
computer-readable media include, but are not limited to: 
magnetic media such as hard disks, floppy disks, and mag- 
netic tape; optical media such as CD-ROMs and holographic 
devices; magneto-optical media such as floptical disks; and 

45 hardware devices that are specially configured to store and 
execute program code, such as application-specific inte- 
grated circuits (ASICs), programmable logic devices (PLDs) 
and ROM and RAM devices. Examples of computer code 
include machine code, such as produced by a compiler, and 

5Q files containing higher level code that are executed by a 
computer using an interpreter. 

Although the foregoing invention has been described in 
some detail for purposes of clarity of understanding, it will 
be apparent that certain changes and modifications may be 

55 practiced within the scope of the appended claims. 
Therefore, the described embodiments should be taken as 
illustrative and not restrictive, and the invention should not 
be limited to the details given herein but should be defined 
by the following claims and their full scope of equivalents. 

(50 We claim: 

1. A method of delegated loading of an application onto 
a smart card, said method comprising: 

assigning a security domain of the smart card to an 
application provider; 

65 providing a key set to application provider for the security 
domain assigned to the application provider, wherein 
the key set is not known to the issuer of said smart card; 
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approving of said application by an issuer of said smart 
card, wherein the approving of said application by an 
issuer of said smart card, comprises: 
certifying said application; 

creating a data authentication pattern for said applica- 
tion; 

creating a command for loading said application; 
adding said data authentication pattern to said load 
command; 

creating a command for installing said application; 
adding said data authentication pattern to said install 

command; and 
delivering said commands to said application provider; 

inserting the smart card into the card acceptance device 
subsequent to the steps of approving said application, 
creating said application authentication pattern, and 
appending said application authentication pattern, and 
prior to the steps of receiving the load command, and 
verifying said load command, wherein said delegated 
loading is performed after issuance of said smart card 
to a consumer; 

receiving a load command from the application provider 
via a card acceptance device, said load command 
including an indication of an application to be loaded 
and an appended command authentication pattern; 

verifying said load command using said command 
authentication pattern; 

receiving said application from the application provider 
via said card acceptance device, said application 
including an appended application authentication pat- 
tern; 

verifying said appUcation using said application authen- 
tication pattern; and 

loading said application into memory of said smart card, 
whereby said application provider is allowed to load 
said application onto said smart card. 

2. A method as recited in claim 1 wherein said command 
authentication pattern is generated by an issuer of said smart 
card using a cryptographic technique, and wherein verifying 
of said load command includes: 

recalculating said command authentication pattern from 
said load command using said cryptographic technique, 
whereby said command authentication pattern and said 
recalculated command authentication pattern may be 
compared to provide verification of said load com- 
mand. 

3. A method as recited in claim 1 further comprising: 
receiving an install command from an application pro- 
vider via a card acceptance device, said install com- 
mand including an indication of an application to be 
installed and an appended install authentication pattern; 

verifying said install command using said install authen- 
tication pattern; and 

installing said application on said smart card, whereby 
said application provider is allowed to install said 
application onto said smart card. 

4. A method as recited in claim 3 further comprising: 
receiving a load command from an application provider 

via a card acceptance device, said load command 
including an indication of an application to be loaded 
and an appended load authentication pattern; 

verifying said load command using said load authentica- 
tion pattern; and 

loading said application on said smart card, whereby said 
application provider is allowed to load said application 
onto said smart card. 
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5. A system for delegated loading of an application onto 
a smart card, said system comprising: 

a host computer under control of an application provider; 
a software application included in said host computer to 
^ be loaded onto a smart card, said application including 
an appended application authentication pattern pro- 
duced by an issuer of said smart card that verifies said 
application to said smart card; 
a smart card acceptance device linked to said host com- 
^ puter; and 

a smart card included in said card acceptance device, said 
smart card including code arranged to verify said 
application using said application authentication 
^ J pattern, whereby said application provider is allowed to 
load said application onto said smart card. 

6. A system as recited in claim 5 wherein said host 
computer comprises: 

computer code to assign a smart card security domain to 

20 the application provider; 

computer code for providing a key set to the application 
provider for the security domain assigned to the appli- 
cation provider, wherein the key is not known to the 
issuer of the smart card. 

25 7. A system as recited in claim 6 further comprising: 
a load command included in said host computer said load 
command comprising an appended command authen- 
tication pattern and code for loading said software 
application; and 

30 code within said smart card arranged to verify said load 
command using said command authentication pattern, 
whereby said application provider provides said load 
command to said smart card. 

8. A system as recited in claim 7 funher comprising: 

35 an install command included in said host computer said 
install command comprising an appended install 
authentication pattern and code for installing said soft- 
ware application; and 
code within said smart card arranged to verify said install 
command using said install authentication pattern, 
whereby said application provider provides said install 
command to said smart card. 

9. A system as recited in claim 6 further comprising: 

an install command included in said host computer that 
has an appended install authentication pattern; and 

code within said smart card arranged to verify said install 
command using said install authentication pattern, 
whereby said application provider is provide said 
install command to said smart card. 

10. A method as recited in claim 6 wherein said crypto- 
graphic technique provides authentication and integrity for 
said application. 

11. The system as recited in claim 5 further comprising: 
J J a network connection linked to the smart card issuer; 

computer readable code for sending the application from 
application provider to the smart card issuer; 

computer readable code for receiving the approved appli- 
cation and an appended application authentication pal- 
^0 tern from the smart card issuer; and 

a storage device for storing the application and the 
appended application authentication paltem. 

12. A method of delegated installation of an application on 
a smart card from an application provider, said method 

65 comprising: 

sending an application from the application provider to a 
smart card issuer for approval; 
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receiving an approval application with an appended install 
authentication pattern from the smart card issuer; 

storing the approved application and appended install 
authentication pattern at the application provider; 

loading the stored approved application onto a smart card ^ 
from the application provider; 

receiving an install command from an application pro- 
vider via a card acceptance device, said install com- 
mand including an indication of said application to be 
installed, install parameters and an appended install 
authentication pattern; 

verifying said install command using said install authen- 
tication pattern; and 

installing the approved application on said smart card, 15 
whereby said application provider is allowed to install 
said application on said smart card. 

13. A method as recited in claim 12 wherein said install 
authentication pattern is generated by an issuer of said smart 
card using a cryptographic technique, and wherein verifying 20 
of said install command includes: 

recalculating said install authentication pattern from said 
install command using said cryptographic technique, 
whereby said install authentication pattern and said 
recalculated install authentication pattern may be com- ^5 
pared to provide verification of said install command. 


14. A method as recited in claim 12 further comprising: 
approving of said install command by an issuer of said 

smart card; 
creating said install authentication pattern; 
appending said install authentication pattern to said install 

command, whereby said smart card is reliably assured 

that said install command has been approved by said 

issuer; and 

inserting the smart card into the card acceptance device 
subsequent to recalculating said install authentication 
pattern creating said install authentication pattern, and 
appending said install authentication pattern. 

15. A method as recited in claim 14 wherein said del- 
egated install is performed after issuance of said smart card 
to a consumer. 

16. A method as recited in claim 15 further comprising: 
assigning a security domain of the smart card to the 

application provider; and 
providing a key set to the application provider for the 
security domain assigned to the application provider, 
wherein the key set is not known to an issuer of said 
smart card. 
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ABSTRACT 


A method of securely^'' transfeiring^data^juch as progra m^ 
Sata._to^jJsmart"card^Q.) is dig logdx In order to^'be 
applicable in^non-sccure environments, the method of the 
invention involves a one-way authentication mechanism, 
comprising the use of a series of interrelated authentication 
values (RO, Rl, R2, . . . ). Further security is achieved by 
using commands (INIT, TRAN) which are each provided 
with an authentication code (MACO, MACl, . , . ). In order 
to [tg jisfeF"data~on lylo selcctcd"cards}vthe card may accept 
transfer commands~only~if~tf~card~prorile (CP) matches a 
distribution profile (DP). 
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METHOD OF SECURELY MODIFYING DATA To achieve these and other objectives, a method of 

ON A SMART CARD securely modifying data in a smart card comprises according 


to the present invention the steps of producing an initiation 
BACKGROUND OF THE INVENTION command comprising an initial authentication value and , 


. . ... .u 1 r 1 5 producing an initial authentication code based on the com- 

ITie present mvention relates to a method of securely j^^^^ .^-^-^j ^^1^^^ producing-aHeast^one-transferx P 

modifymg data on a smart card More specifically, the command comprisinrdatrto be transferred and produci^^ 

present mvention relates to a method of securely loading or siIh^uenf^theniicatinr^ri^T^l^thlh^ 

deleting data, and creating and deleting data structures, on a and a subsequent "authentication value derived from the ^ 

smart card, which method is also applicable in environments initial value, txa^fen^g^t^'T^Q^^ th^ifTutHentiA f ^ C'W 

where so-called challenge — signed re sponse auth entications ^° cati oncodesl hus pr oduccdlb Ih esmart card^^authenticating 

are not possible. The data concerned naay_com prisc cittieT] ) the commands in the smart cardbycfiecking the authenti- 

^executable (program) data,_i.e. conama^5]or~static~(non= cation codes and checking the subsequent authentication 

r programXdata, or both. Tbe^so'called static data' ma y com^ values derive d from th e initial value, a'nd"stori n'g"tKe"tfaris^ 

^ prise filc~structur^jnd/or_ data structujes^^"' (fer redHatrin the ca rdT^ 

In modem payment systems, the use of electronic pay- That is, the initiation command provides the card with an 

ment means becomes increasingly important. Electronic initial authentication value, which value is also used to 

payment means, such as memory cards and smart cards produce the subsequent authentication valu es comprised in ^ ^ 

(generally called IC cards), are gaining acceptance as their ^he transfer commands.jBy^derivmg the subsequent values) 

applications are expanded. In many countries electronic ^and-comparing'these derived values with the values com::> 
cards are being used for public telephones and the like. 20(2nsedmjli^j^^^^^^ the card can 

Advanced cards are capable of containing electronic fectively chjcluhe authenticity ofl^^ 

„ M . , .... . .u r o u 1 I In addition, (an authentication code, such as a hash , panty\ 

purses , in addition to other functionalities. Such advanced ' . , /xv A-i^\-- -^-il,— -l^ 

* ' • ' 1 1- • bits or a message authentication code (MAC) in general, is 

payment means contain, in addition to a memory, a proces- , , -c -ft — — — t—.t — f-.u- - —^^^ — ^ a 

. ..1 used to fVeniy the authenticity of the received commandsx 
sor capable of running suitable programs. an additioT^irprot^i^i.4l5fovided w^ 

It should be noted that in this text, the terms smart card or advantageous when the data transferred comprise card com- 

card will be u sed to d enote electronic pay ment m eans having ^^^^^^ having no built-in protection mechanism, i.e. for 

(at^leasj onejmegrated~ele^tronjc circuit compris ing-a'pro^x^ protectedly transferring unprotected commands. The com- 

cessor and^mem^^ actual shape of a so-caUed smart^ bination of the use of authentication values and authentica- 

card is not of importance. tion codes, as set out above, provides an effective protection 

The programs running on the processor of a smart card against the fraudulent manipulation of the data transferred, 
deter mine th e services offe red by the c ard, that is, the in order to achieve a further check mechanism, the 

{functions_^nd^^^^^ purse, user initiation command preferably further comprises t he num ber 

identification, loyalty program) of the smart card depend on of transfer commands. ThisrenaBles~thircaFd' to checg? 
the software present in the card. As time passes, the need 35 fwhelhcf ^ll transfer cornmands have been received, and") 

often arises to update the programs of the card, for example (preventTthe unnoticed'loss of transferred data^ 

in order to_add_anew function or to improve a^_exisling ^^d%^anta^ously, the initiation comm^and is arranged to 

functionTTo this end, the card should be able to accepxnew^ prohibit the card from accepting commands other than 

*progra„ms which_may.replace,pther^rograms;-However, it transfer commands. In this way the transfer of data to the 

must be ascertained that the newly loaded programs are 40 card can not be interrupted by the execution of other 

valid. Authentication of programs can relatively easily be commands. Also, it is prevented that partially transferred 

accomplished by using a secure data exchange protocol ^g^^ gj.^ manipulated, 
fl^- , whtTsd!iir^^^^g^^^a^r^r^X:^^ Preferably, eaaTPaiisfeT^SFSiFdTwlHerc^ 

«^"2H?L(hav.hg, for instance, a so-called secunty module in (;s5q5|^^^5|er;\ITiis'allows'l,^ on"th^ 

\C^--^ ""^'^^ ^"y^ """^^ f 'i'J'^'y ^^°""^}- ^"""^ " « ^i^t^^Tximdl^'it, in the correct order, of the transfer 

'r^'^ secure protocol ma^mpnse a challenge-signed r^ponse commands, but also provides the possibility to retransmit a 

protqcoLjExamples of protocols-for-exchangmg Jata ^^^^er of transfer commands if transmission errors 

^between a smart card ^and a termmal are disclosed^ in-e.g.) ^^^^^^^^ ^^ ^^c authentication codes) have occurred. 

VS. Pat. No. 5,161,231 and European Patent Application , j ,^ y ,^ possibility to undo a number of 

, 0,559.205 (corresponding with U.S. Pat. No. 5,369,760)^so ^^^^^^^ commands. 

, which are incorporated by reference m this text. ^ ^ commands may in principle be used to 

However, in case a secure terminal is not present, such a .rg^gfe^ j^,, ,,3^5^^^ ^3,^ ,j,us not only 

secure protocol involving e.g. a challenge-signed response comprise e.g. monetary balances and lists of telephone 

cannot be used, as the security of such a protocol depends on p^^tcts (static data), but als?orrc-or morc~card-coiirmands, 
the trustworthiness of the termmal. 55 r(cxeciitable-data); (Such"ro mrnands may e.g. comprise an"> 

SUMMARY OF THE INVENTION (UPDAT E co mmand^^Avhich-updates oiie_or morejnemory_3 

locations, or a CREATE comman"d"which allocates memory 

It is an object of the invention to overcome the above- locations. Apjrt.from existing commands. Cnew'card ~co5il 

mentioned and other disadvantages of the prior art and to jmands'mayralsoWcomprised-i f\>^Oi \0 

provide a method which allows data to be loaded in a smart 60 command.may_be_slore.djn memory, butmay also be difectly\*^ ' 

card in a secure manner, even in non-secure environments. exeoited-upon-transfer to the'clrd.fe waTaiTefficient 

It Bj^further object of t he inve ntion to provide;a method fgr> ^ay of"itodifying-the-m'einorycontenls of the card is 

\ \ securely tr ansfe rring d ata to a sm art cardj^which method achieved. 
Cv**^ comprises a one-way authentication mechanism. It is still a 

further object of tl^ inventionjo provide^^a melhod foTlas BRIEF DESCRIPTION OF THE DRAWINGS 
Csecurely transferring data jo_a^raart card,_Vhich method FIG. 1 schematically shows a smart card as may be used 

comprises a store and forward protocol. in the method of the present invention. 
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FIG. 2 schematically shows the integrated circuit of the In step 106,<aIla5pIisCiaiLiated_in_.which^the-lra^ 

smart card of FIG. 1. Sommanarpidjheir^ 

FIG. 3 schematically shows the commands as may be ^^^lues^aLcjaetemi^d commands are prefer- 

used in the method of the present invention. ^^Jy provided with a sequence number (S), which is set to 

FIG. 4 schematically shows by way of example how a set ^ ^ 1° . ... , 

of commands may be produced according to the method of ^ '? ^JfP ^^^''^^ authenUcaUon values Rl R2 . . may be 

* • denved from the imtial authentication value RO by e.g. usmg 
the present mvention. , . .ai«.-i 

^ a random number generator. Alternatively, a message 

FIG. 5 schematically shows by way of exemple how a set authentication code process (e.g. according to the ANSI 

of commands may be processed by the card according to the X9.19 standard) may be employed for producing the aulhen- 

method of the present invention. tication values, the resulting "MAC" being used as aulhen- 

FIG. 6 schematically shows a system for modifying data tication value. In this process, one or more keys may be 

on a smart card. used, such as the secret key K. 

T^vrxAnj Anv cn^Di-vT^Tx^cKr-rc proceduxe of FIG. 4, the derivation of authentica- 

EXEMPLARY EMBODIMENTS ^^^^ ^^^^^^ ^^C) should be performed at least N times. It 

The smart card or IC card 1 shown schematically and by should be noted that an even greater security can be achieved 

way of example in FIG. 1 comprises a substrate 2, in which by using e.g. every other derived value, that is by skipping 

ajTintegrated^circmn^ integrated circuit is values, in which case the derivation should take place more 

provided with^ontactsXforrantacting a card reader or the than N times. The authentication values Rl, R2, . . . should 

like. It should be noted that the present invention can also be be related, i.e. derived from each other, but need not be 

applied in the case of so-called contactless smart cards. successive results of the derivation process. Thus, only e.g. 

The integrated circuit 10 shown schematically and by way RO, R2. R4, . . . c ould be used. 
of example in FIG. 2 comprises a processor 11, a memory 12 In step 108,QEeIdata-to-be-transfen:edlfre:fetcfiea>e.g. 

and an input/output circuit 13. The memory may comprise a from the data table mentioned earlier. These data are used in 
volatile (RAM) memory part for temporarily storing data ^5 step 109 to produce the transfer (TRAN) command, which 

and a non-volatile (ROM) memory part for permanently or comprises the command proper (instruction code), an 

semi-permanently storing data. ^Fhe latter part is preferably authentication value (R[N]), the sequence number (S), and 

an EEPROM type memory. The data stored in the non- the data (DATA[N]). In step 110, an authentication value 

volatile part may contain both programming data (MAC[N]) is calculated like in step 104. The transfer 

(instructions, programs) and payment data, i.e. data relating command and its associated authentication code are stored 

to monetary transactions. It will be understood that a sepa- in step 111. 

rate memory (not shown) may be provided to store the After incrementing the.scqucn £c number S in s tep 112, the 

instructions of the processor 11. sequence i^mb0-_SJs-comp_ared3vith,the_uumber^ of data 

YhG method of the invention, asjlepicted^hematically items in step 113. If all data items have been processed, this 
and by way of example inrFIGS7 ~4 and 5 , involves'thelgg part of the method is teiroinated in step 114, Otherwise, 

ftfansfer^ data ffonTan^outei^^ controjjetums to step 107. 

r gtbvider) to a card, such as the cardTof FIG . 1. The transfer Qn.FIG.S^^iTsh^own^ow theseTof commandTproduced^) 
of ^ata according to the invention involves [producing a set^ (according~to~FIG~4^is processed by jhe_smart,card^Afta^ 

of 'colMaands^ such as depicted in FIG. 3.^An^initiati6n activ^tionnof "thic'caiSi"ih^tep 200, the initiation command 

command (INIT) is followed by one or more transfer (INTT) is received in step 201. First, its authentication code 

commands (TRAN). All commands comprise parameters (MACO) is verified in step 202. This preferably involves the 

(RO, Rl, . . . , N, . . . ) and all transfer commands comprise re -calculation of the authentication code and €ompanng"tK^ 

data (DATAl, DArA2, . . . ). The parameter cornprise jrc-calculated"Code~(MACO')-"with~the~r^CB'ived code) 
authentication values (RO, Rl, . ). 'AssociatedTwith eacB ^MACp)rIfthexodeis validrthe-pnscedure iscontinued with 
Command is^anjuthe^atjonT^^ . . . ). 45 step 203. Otherwise, the procedure is exited. After an exit, 
(ITie wa y Jhiir^t~of 'commands ("scnpt'Xis prpduce.cTls] special measures may be taken, such as producing a request 

explained with reference to FIG. 4. for retransmis,sion. For the sake of clarity, this is not shown 

The procedure is initiated in step 100. In step 101, the in FIG. 5. 
number of transfer commands (TRAN) is determined. Data In step 203, the values of N and RO (initial authentication 
items to be loaded in the smart card are preferably arranged 50 value) contained in the initiation command are stored for 

in a table beforehand. The number of data items (N) deter- later use. Pr^feraiyj^jhc-card^^^ 

mines the number of commands (TRAN) necessary to load ^only-transfer com mands can be acc epted;- thus preventing 

the data items into the card, llie number (N) of transfer lh"e~interruplion ^TThe procedure. Preferably, the card 

commands can t hen b e^ determined by cerg7"coulitinOl'*& remains in this "locked", that is tran.sfer-only state until all 
nm]iiber50tem^in-the.tablej(n6t shown). 55 transfer commands have been received. As stated above, the 

"lnstep^l02, the initial authentication value RO is fetched. total number (N) of transfer commands is contained in the 

The value RO may be predetermined, but is preferably INIT command. 

generated by e.g. a random number generator. The value RO Step 204 prepares for a loop in which the transfer com- 

is temporarily stored for later use. mands are processed, A counter T, which corresponds with 

In step 103, the initiation command (INIT) is produced by 60 the sequence number S of FIG. 4, is set to one. 
assembling the command code proper, the value RO and the In step 205 a transfer command (TRAN) is received. The 

number N. An authentication code MACO is calculated in fi'rstltimOtcp jOgis icxccutc d , the first transfer command 

step 104. The code MACO may e.g. be calculated according TRANl will be received. It will be understood that all 

to the ANSI (American National Standardization Institute) commands may be "received" virtually simultaneously, and 
X9.19 standard using triple encryption. In step 104 the 65 that in step 205 the actual processing of the individual 

initiation command INIT and its associated authentication transfer commands begins. VtiG Grst transfer command, as 

value MACO are (temporarily) stored. shown in FIG. 3, has the structure: 
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TRAN(R1, 1, DATAl. . . . MACl, where TRAN 
represents the command proper, Rl is the first subse- 
quent (that is, second) authentication value, 1 is the 
sequence number (S), DATAl is the data contained in 
the command, and MACl is the authentication code of 
the command. 

In step 206 of FIG. 5 a double test is performed. First, the 
authentication code MAC[T] of the transfer command is 
checked for its validity, e.g. by reproducing the code and 
comparing the result (e.g. MACl') with the received code 
(e.g. MACl).cIttEeIcodes-are-not equalrthe routine.is exited, 
following which the'~co'rama'n'd"is rejected and a 
re- transmission request may be issued. The card may contain 
the key or keys necessary for producing an authentication 
code. It will be understood that instead of reproducing the 35 
code, some other vaUdiiy check may be employed. 

Furthermore, the card checks the received sequence num- 
ber S to sec that all transfer commands are received in the 
correct order. If the received sequence number S is not equal 
to the counter T, the routine is exited, as described above. 

If both the authentication code and the sequence number 
are found to be valid, the routine continues with step 207, in 
which the authentication value R is derived from the previ- 
ous value. In case the first transfer command is being 


the effect of the transfer commands which were processed. 
In order to undo the transfer commands of the failed series, 
a new series of commands may be provided which has the 
effect of deleting or undoing the results of the first series. 

In the examples set out above, it is assumed that the card 
reproduces the authentication values Rl, R2, etc. As this 
requires a certain amount of processing power and process- 
ing time, it is possible to simplify the procedure by using the 
authentication code of each preceding command as authen- 
tication value. R eferring to FIG. 3, thfe^ould imply^tfiat tfie, 
cvaluc'of"Rl""is cbosen to 6e~equ aT to M ACGfR 2~is'equ BTloy 
^MAClTetc^^e initial authentication valinrROlrfa'yrin'tHat 
case7be omitted. Such a scheme has the advantage of a 
greater speed and simplicity at the cost of a less effective 
security. In order to increase the level of security in the 
simplified procedure, it is possible not to use the (preceding) 
authentication code proper, but a value derived from the 
code as authentication value: R2=F(MAC1), where F is for 
j^examplelTHash or parityfunction. 
20 ^leries'of'com m^ands, as e. g. depicted jn TIG. 3, ma y^be^ 
iCffered to one or^more~cards7\^In order to controPthe 
distribution ofT'specific'series'of commands, the initiation 
command (INTT) prefe rably comprises a distr ibution pjpfile 
((OT)^achj£comp^red^ 


processed 0 = 1), Rl is derived from RO using a key K. This 25 card^The initiation commandos only executed if the distri- 


derivatioD in step 207 corresponds to the derivation in step 
107 of FIG. 4. 

The correctness of R is checked in step 208. If the derived 
authentication value (R') is not identical to the received 
value (R), the routine is exited. This ensures that all transfer 30 
commands are authentic, i.e. provided with interrelated 
authentication values as derived in the routine of FIG. 4. 

If the authentication value R is found to be correct, data 


Bufion profile (DP) and the card profile (CP) match. The 
profiles may contain e.g. 16 bytes of user and/or card related 
information. The distribution profile contains information 
specific for a set of cards and may therefore contain wild- 
cards which are replaced by corresponding information of 
the card profile before the profiles are compared. The term 
"match" should therefore be understood to include the 
corresponding of wildcards. ITie profiles can be used for 
only checking the authorization of the card by including in 


contained in the transfer command are stored. In general, 
Cth-esTHa ta may bV^tored~ih^the-memory^flhc~card?N35 service profile a flag mdicatmg that the card is not to be 

H5^;^^^flhe diu^S5^^r^dl;o5^ P^^ ^^^^^fer commands accepting mode. By way of 

^ example it is assumed that each profile comprises 16 bits 


The profiles: 

CP=1001 0001 1010 0111 and 

DP=1001 0001 1010 1001 
match if the four least significant bits are considered as 
wildcards, i.e. are not taken into consideration. In other 


tions for the processor of the sjnart~cardrthe'ge~card com? 
mands may beTclirectly'executed. In the latter' caseTlhe 
transfer command may load tfie^smart card command con- 
cerned directly into the instruction register of the smart card 40 
processor and make the_processor,execute^ Jh e com rnand . 
Traiisfer-command^jnay_comprise_a-flag_to_indicate_^S^ 
rriature of the transfciTed~dMa"(commandsor otheTdatj) and^ words, the distribution profile: 
Ytheir destina tion (memor y or instnictioiTefister); The direct DP=1001 0001 1010 1001 
execution of transferred card commands'proviSes an effec- 45 "matches" all card profiles having 1001 0001 1010 as the 
tive way of loading data onto a card, or of changing and/or first 12 digits. Cards having another card profile (CP) will 
creating data structures on a card. not execute the initiation command and will thus not allow 

After storing of otherwise processing the data in step 209, their data to be modified, 
the counter T is incremented in step 210. Subsequently, in The method of the invention, as will be apparent from the 
step 211, the value of T is compared with the (expected) 50 above, involves basically three stages 


number of transfer commands. If all transfer commands 
have been processed, the routine is terminated in step 212, 
and the state in which (preferably only) transfer commands 
are accepted is discontinued. Otherwise, the next transfer 
command is received in step 205. 55 

The sequence number S containe d in th e transfer com- 
mands ser ve seve ral purposes. I^the„ first place]jthey p 
(^alncchanism Jp_ch^cin in which" the transfer^ 

commands~aTc reccivcd"and processed. In t he second pjace> 
they^rovide a mechanism to resume an interrupted 60 
sequence of transfer commands. If for example a transmis- 
sion error occurs and the routine of FIG. 5 is exited after, say, 
5 out of 10 a series of transfer commands have been 
processed, the last sequence number S and/or the counter T 
can be used to resume the processing at the correct command 65 
when the series of commands is retransmitted. Also, the last 
sequence number S and/or the counter T can be used to undo 


1. Producingasetof commands, i.e. one initiation command 
and as many transfer commands as required to transfer the 
data in question. This involves .inoducingfa'set ^f inter> 
(rdaled~authentication-values:^ EaclTcommand is further 
provided ~with~an~authentication code (MAC). 

2. Transmitting the set of commands to the card. 

3. Executing the commands on the card after checking the 
authenticati on codc _jof„ca_ch^o m ma nd. Thc~cxecuting 

^invojyes.in.the.casc.ofahearansfcTcommands the chcck^ 
ing of-iraT-thc authentication values and theb the loadings 

r of the rel evant data in memoryW"(irrthe~case~of a card 
command) in th"e~instruction~ register of the processor of 
the card. 

The method of the present invention thus enables the secure 
transfer of data, e.g. card commands, to a smart card by 
providing a double protection mechanism: the related 
authentication values guarantee that the sequence of 


02/18/2004, EAST Version: 1.4.1 


5,856,659 

7 8 

received data is unaltered, while the authentication ccxles 2. A method according to claim 1, wherein the initiation 

accompanying each command provide protection of the command (INIT) further comprises the number of transfer 

transferred data. In the case where the transferred data are commands (N). 

smart card commands, the method thus provides protection 3. A method according to claim 1, wherein the initiation 

of non -protected commands. 5 command (INIT) is arranged to prohibit the card (1) from 
A system for modifying data on a smart card is^henaad^ accepting commands other than transfer commands 
cally shown by way of example in FIG. 6. ^?^ySeEB^ (TRAN). 

^tomorisgyfea^teato 4. A method according to claim 1, wherein each transfer 

ItSSESnSSSr Tf^BSSp command (TRAN) further comprises a sequence number 

^^^ei7^tS ^rA^set(o^f<(^m e.g. represented in the (SN). 

table of FIG. 3, is prepared" in the computer 7, Then the 5. A method according to claim 1, wherein the transfer 
commands of the set are sent via the data link 6 to the card data (DATA) comprise a card command (e.g. UPDATE), 
reader/writer 5, which transfers t he command s to the smart 6. A method according to claim 5, wherein a card corn- 
card 1. m'glsm^^ pgKx^^ mand (e.g. UPDATE) is directly executed upon transfer to 
laboxenthuastonfflpS^^ _ c^^^- 
'^t^lll'b■funderstood by those skiUed in the art that the 7. A method accordmg to claim 5, wherein a card corn- 
embodiments described above are given by way of example IS a protected command according to the ETSI 
only and that many modifications and additions are possible f?il,^«P^^" Telecommunications Standardization lastitute) 
without departing from the scope of the present invention. rE9.recommendation, the value needed for protecting the 
We claim* r r command corresponding with the authentication value. 
^ ^ . . ^ 1 j-r • J • , 20 8. A method according to claim 1, wherein the authenti- 
1. A method of securely modifying data in a sman card . , /»*Ar-i xjf \ . j j- 

• . . r cation codes (MACl, MAC2, . . . ) are generated according 

(1), the method comprising the steps of; to the ANSI X9.19 standard. 

producing an initiation conamand (INIT^ compnsmg an , ^ ^^j^^ according to claim 1, wherein deriving the 

mitia authentication value (R^ and producing an subsequent values (Rl. R2. . . . ) involves the use of a secret 

initial authentication code (MACO) based on the com- ^5 j^^gy 

mand and the initial value (RO), A method according to claim 1, wherein the initiation 

producing at least one transfer command (TRAN) com- command (INIT) comprises a distribution profile (DP) and 

pnsing data (DATA) to be transferred and producmg a the card comprises a card profile (CP), and wherein the 

subsequent authentication code (MACl, MAC2. . . . ) initiation command is only executed if the distribution 

based on both the command (TRAN) and a subsequent 30 profile (DP) and the card profile (CP) match, 

authentication value (Rl, R2, . . . ) derived from the n method according to claim 1, wherein the initiation 

initial value (RO). command (INIT) puts the card (1) in a transfer state in which 

transferring the commands and their authentication codes only transfer commands (TR>^ are executed. 

thus produced to the smart card (1), 12. a method according to claim 11, wherein the card (1) 

authenticating the commands in the smart card (1) by 35 remains in the transfer state until it has received all transfer 

checking the authentication codes (MACO, commands (TRAN), as indicated by the number (N) of 

MACl, . . . ) and checking the subsequent authentica- transfer commands contained in the initiation command 

tion values (Rl, . . . ) derived from the initial value (INIT). 
(RO), and 

storing the transferred data (DATA) in the card. ***** 
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ABSTRACT 


A process for transforming an original source code contain- 
ing a description of a stub method employed in an object 
interaction into another source code corresponding to an 
environment on which a program is executed. The original 
source code is described with a predetermined programming 
language and contains information concemingjthe stub 
method to be used in the ob ject interactiorf^einformati^^ 
fis'd eseribedln a fo rmat whic lTiscofmiron to a pluHlU)^ 
<;difererirp^gra^^ transfonna^ 
tion is conducted with reference to a registered information 
corresponding to the program execution environment on 
which stub method is to be executed into another source 
code described with the same programming language as the 
original source code in a predetermined format correspond- 
ing to the program execution environment on which the stub 
method is to be executed. 

12 Claims, 4 Drawing Sheets 
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SOURCE CODE TRANSFORMATION may be, for example, a language detennined by the CORBA 

PROCESS AND RECORDING MEDIUM (Common Object Request Broker Architecture) which is a 

rule for implementing object-oriented distributed processing 
environments. 

BACKGROUND OF THE INVENTION 5 More specifically, referring to FIG- 4, the process of 

1. Field of the Invention forming an application program for object interaction begins 
^ . . , , ^ with the formation of three kinds of source codes which are 
TTie present invemion relates to a source code transfor- ^ ^^^^ ..fl^^,^ ..^^^^j.. ...^i^^,, ^^^^^ ^^^^ 

mation process for transformmg source code includmg a ^ — ^ j • /• 

J . ,r . u- . • . J 1 The-first^source code contains stub method information 

description concerning an object interaction method known m , ^-tr - t — = c — -irii 1 

. u -1 • . J u ■ J . J * described m the interface definition language. Tnis means 

as a stub method into source code which is adapted to a . x. - r u jft_? - 

, rp, . • .* 1 that the interface to be used for the object interaction is 

program execution environment. The present invention also .0 , /> , , r-i^ a ■ 

fc Z^^^^^r^^A ..riiu o ^^rr,«i,t<.r r*.o^oKu \™ dcfined by thc first source code. In FIG. 4, a file fl in which 

IS concerned with a computer-readable recording medium c . _, • ... • • j- . j . ji** 

L- L . J . r f the first source code is written is indicated as Test.idl . 

which stores a source code transformation program for " ^^^^v^v^^v " 

implementing the source code transformation process. 15 Th.esecond s ource code c ontains server object informa^ 

Details of certain features of the present invention are ^^O" descnbed m a programming language such as C++, 

described in European Patent Application No. 0.753,811 Al ^^^^ ^^^^nd source code contains the portion of the 

entitled "Data processing method and device" and filed by ^^ver object information other than the object interaction 

the same assignee on Jul. 12. 1996 claiming a Convention information descnbed in the first source code. The second 

Priority on JP 178625/95, filed Jul. 14, 1997, the complete 20 ^^^^^ fnnhcr contains, for example, a procedure for 

disclosure of which is hereby incorporated herein by refer- ^^""'g* stub method described by the first source 

c^QC^ code, a method for generating a thread which performs 

-T>* •4- f.i.ni*jA_4 processing based on the received message. In FIG. 4, a file 

2. Descnption of the Related Art « 1 u- .u ^ ^ • . ^ u u i^ . 

^ ^ ^ iZ describing the second source code is represented by Test 

In general, object-oriented programming frequently uses svc_proc cc" 

object interaction methods. The term "object interaction" is 25 ~Ti!7'j~~- j . • .u i- . u- . • r 

vc . • . r 1 r The-third source codet contains the client obiect 1 nforma- 

used in this specification to mean, for example, a process for , > , , u 1, • 

^ - ,. , rL , ■ tion descnbed in a program mins lansuatie such as C++. It IS 

sendmg a message from one object to another. Thc object ^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^ .^^j^^^ ^.^^ 

mleraction is an essential service offered by an operating ^^^^^ ^^.^^^ information other than the object interaction 

system in object-oriented^^ information described in the first source code. Tlius, the third 

(Melhods-employed in object,intej[act ion are gen^rally"> code contains a description for implementing a main 

fr^err ed to as "stub m ethods':>Thus, a stub method is used function, e.g., connection to an appropriate service, in the 

in objectnoriented programming for the purpose of sending form of an application program. In FIG. 4. a file O in which 

a message from one object to another. In the following i^ird code is described is represented by "Test.cc" and 

description, the object firoco^which the message is sent will "Test.h", The "Test.h" file is an include file which is incor- 

be referred to as a "client object", while the object which porated in the "Test.cc" file 

receives the message wiirb-eref^rred to as a *J^^er3bject'2> The first source code described in the interface definition 

For instance, when it is desired to execute the procedure language is transformed by a stub generator 101 into source 

of a server object on another computer linked through a code described with the same programming language as that 

network, a message is sent through the network from the used for the description of the second and third source codes, 

client object to the server object to be executed on the other Thus, the stub generator 101 generates a stub method which 

computer. It is thus possible to execute the procedure of the is described by a programming language such as C++ rather 

server object on the other computer linked through the than by the interface definition language, 

network. It will be understood that a remote control opera- ^^^^ specifically, the transformation performed by the 

tion for calhng a procedure to be executed on a diff-erent gt^b generator 101 generates from the file fl in which thc 

computer through a network can be peri^ormed in the same first code is described, a file f4 which contains a stub method 

way as that performed by a local procedure caU interface. description for the server object, a file f5 containing^tub 

In general, a stub generator is used for generating a stub method description for thcjrjient obj£ct,jn"d'anincludrfile> 

method. More specifically, such a stub generator reads fffi^hich is to be commonly uscdbyogec ts involved in thc j^ 

source code containing information concerning a stub jg {object interacjtion.^ 

method described in a certain programming language and FFIG. 4, tlieTile f4 containing the stub method descrip- 
generate s a st iib method from the rcad^source code. In most tion for thc server object is represented by "TcstStub.cc" and 
casesrthe sug^gcncrator has both'a'mnction'for-gegra^ "TestStub.h". The "TestStub.h" file is an include file incor- 
a stu^ meth"dg co'nceming-the-cUent^object-whic^^^J^^ porated in the "TestStub.cc" file. The file f5 containing stub 
^lessage scnderand_a^u^^ a smb^thodjj^j method description for the client object is represented by 
concerning the server object which is the messagereceiver. "TestProxy.cc" and "TestProxy.h". The "TestProxy.h" file is 
With these functions, the client object and the server object an include file incorporated in the "TestProxy.cc" file. The 
can be set up very easily with a high degree of versatility. include file f6 commonly used by the objects involved in the 
A description will be given of a process for forming a object interaction is represented by "lestEntry.h" and "Test- 
program by using a stub generator 60 Msg.h". 

Formation of the program using a stub generator includes Then, compilation is performed on each of the file G 

describing a program for a non-object-interactioo portion by containing the description of the second source code, the file 

means of the C++ programming language and describing a f3 containing the description of the third source code, and 

program for an object-interaction portion by using an inter- the files f4 to f6 generated by the stub generator 101, and the 

face definition language. 'I'he "interface definition language" 65 results of the compilation are linked, thereby forming a 

is a language which defines the interface for the communi- server object executable file f7 for the server object and a 

cation between the objects. The interface definition language client object executable file f8 
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Thus, in the process shown in FIG. 4, the server object 
executable file f7 is generated by an executable file gener- 
ating program 102 having a compiler and a linker from the 
resources which include the file f2 (Tesl_svc_proc.cc) 
describing the second source code, the file f4 (TestStub.cc, 
TestStub.h) containing the stub method description for the 
server object, and the include fil e f6 (TestEr Ury.h, 
TestMsg.h)j_^icGsxommoffl^y 

^arrinjhe_6bjectante?ag At the same time, the client 
oSject executable file f8 is^generated by an executable file 
generating program 103 having a compiler and a linker from 
the resources which include the file f3 (Test.h, Test.cc) 
describing the third source code, the file fS (TestProxy.cc, 
TestProxy.h) containing the stub method description for the 
client object, and the include file f6 (TestEntry.h, 
TcstMsg.h). which is commonly used by the objects taking 
part in the object interaction. 

In general, there are a variety of environments under 
which programs are executed. Any application program, 
therefore, has to be formed so as to be suited to the program 
execution environment. This naturally requires that the 
program execution environment is suited also to the stub 
method which is generated in accordance with the nature of 
the application program and the demand. The stub generator, 
therefore, has to generate the stub method such that the stub 
method is suited to the execution environment of the appH- 
cation program that relies upon the generated stub method. 

Therefore, it has been a conventional practice to prepare 
different stub generators which generate stub methods for 
different program execution environments. Thus, generation 
of a specific stub method requires selective use of the stub 
generator in accordance with the environment in which the 
application program which uses the stub method is to be 
executed. 

Thus, the conventional technique for generating a stub 
method employs an operation performed by a stub generator 
for transforming source code described in an interface 
definition language. The following problems are encoun- 
tered by this known technique. 

Firstly, studying and learning interface definition lan- 
guages are essential in order for the programmer to form an 
application program which uses a stub method, because the 
formation of source code described in a certain interface 
definition language is necessary. In general, interface defi- 
nition languages and programming languages such as C++ 
have fundamentally different formats. Thus, an ordinary 
programmer, even if familiar with programming languages, 
has to spend much time studying and learning interface 
definition languages to such a degree as to become able to 
form a source code with an interface definition language. 
Consequently, much time and labor are necessary for form- 
ing an application program which uses a stub method. 

A second problem pertains to the difficulty that lies in 
ascertaining matching between the interface constituted by 
the source code portion described in the interface definition 
language and the interface corresponding to the source code 
portion described in a programming language such as C++. 
This difficulty will be described in detail. A single applica- 
tion program formed by the procedure shown in FIG. 4 
contains both a portion described in the interface definition 
language and a portion described in the programming lan- 
guage such as C++. As stated before, these two types of 
languages employ entirely different formats. Therefore, 
co-existence of a description in the interface definition 
language and a description in the programming language 
such as C++ makes it extremely dilEcult to confirm whether 
or not the interfaces of these descriptions match with each 
other. 


10 


15 


A third problem is that the conventional stub generator 
cannot be used commonly for a plurality of different pro- 
gram execution environments. Therefore, as stated before, is 
has been necessary to prepare a plurality of stub generators 
which generate different stub methods suited to different 
program execution environments. 

Fourthly, it is to be pointed out that only methods which 
have been determined by the interface definition languages 
are usable as the stub method. Thus, the users are not 
allowed to interactively change the contents of the stub 
method. In other words, the stub methods are determined in 
the procedure for designing the stub generators and, hence, 
are dependent on the stub generators. 'Ilie contents of the 
stub methods therefore cannot be altered by users. 

SUMMARY OF THE INVE^^^ON 


Accordingly, it is an object of the present invention to 
provide a source code transformation process which can 
2Q easily be adapted to a variety of program execution envi- 
ronments and which can generate stub methods without 
using any interface definition language. 

Another object of the present invention is to provide a 
computer-readable recording medium storing a source trans- 
25 formation program which implements the above-described 
source code transformation process. 

To these ends, according to one aspect of the present 
invention, there is provided a source code transformation 
process, comprising the steps of: preparing a primary source 
30 code described with a predetermined programming language 
and containing informati on concerning_ a method to be used 
in an object interaction,®e5ilir6rmatiinr^i^^^ 

SceSiti^i fSTS^^i^nt'sj^^^ a 
35 reference to registered information corresponding to the 
program execution envKon ment on w hich the method is to 
be executed, 
gsoii ng ^ 

40 ■^Sj^ ^lSa^iSj^S^ 

Gvhi^tSl!^ — - — — 

According to another aspect of the present invention, 
there is provided a computer-readable recording medium, 
storing a source code transformation program that imple- 
ments a process comprising the steps of: preparing a primary 
source code described with a predetermined programming 
language and containing information concerning a method 
to be used in an object interaction, the information being 
described in a format which is common to a plurality of 
different program execution environments; and 
transforming, by making a reference to registered informa- 
tion corresponding to the program execution environment on 
which the method is to be executed, the primary source code 
into a secondary source code described with the same 
programming language as the primary source code in a 
predetermined format corresponding to the program execu- 
tion environment on which the method is to be executed. 

These and other objects, features and advantages of the 
present invention will become clear from the following 
description of the preferred embodiment taken with refer- 
ence to the accompanying drawings. 


45 


50 


55 


60 


BRIEF DESCRIPTION OF THE DRAWINGS 

65 FIG. 1 is an illustration of a procedure for forming a stub 
method by means of a stub generator incorporating the 
present invention; 
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FIG. 2 is a diagram showing a process performed by the More specifically, the transformation performed by the 

stub generator; stub generator 1 generates from the file Fl in which the first 

FIG. 3 is an illustration of a class definition conducted in code is described a file F4 which contains a stub method 

accordance with a designator "Active"; and description for the server object, a file F5 containing a stub 

FIG. 4 is an iUuslration of a conventional procedure for ^ method description for the client object, and an include file 

generating a stub method. "^^^^^ ^ commonly used by objects involved in the 

object interaction. 

DESCRIPTION OF THE PREFERRED in FIG, 1, the file F4 containing the stub method dcscrip- 

EMBODIME^^T tion for the server object is represented by "TeslSlub.cc" and 

A source transformation process in accordance with the "TestStub.h". This file F4 wQl be hereinafter referred to as 

present invention wQl be described through illustration of a a "server stub file F4". The "TestStub.h" file is an include file 

procedure for forming an application program which imple- incorporated in the "TestSlub.cc" file. The file F5 containing 

ments object interaction between a client object and a server the stub method description for the client object is reprc- 

object. The recording medium in accordance with the sented by "TestProxy.cc" and "TestProxy.h". This file F5 

present invention stores a program which implements a stub wUl be hereinafter referred to as a "client stub file F5". The 

generator described later. ^Fhe term "recording medium" is "TestProxy.h" file is an include file incorporated in the 

used to mean any type of computer-readable storage "TestProxy.cc" file. The include file F6 commonly used by 

medium such as, for example, a magnetic disk, a magneto- the objects involved in the object interaction is represented 

optical disk, a phase-change optical disk, an optical disk, a by "TestEntry.h" and "TestMsg.h". This file F6 will be 

ROM (Read Only Memory), a RAM (Random Access referred to as a "common stub file F6". As a result of the 

Memory), and so on. described transformation, the source codes contained in the 

Referring to FIG. 1, the process of forming an application ^^^^ and F6 arc described with C++ as in the cases 

program for object interaction begins with formation of f ^^^^^^^ and third source codes, without usmg the 

three kinds of source codes which are referred to as the "first, designator * Active . 

"second" and "third" source codes. Then, compilation is performed on each of the file F2 

Hie first source code contains a stub method description. containing the description of the second source code, the file 

This means that the interface to be used for the object ^3 ajntammg the descnption of the third source code and 

interaction is defined by this first source code. The first ^^^^ to F6 generated by the stub generator 1, and the 

source code is described with C++ extended to allow the use '^'^^^ ^^e compilation are hnked, thereby forming a 

of a predetermined designator "Active" which is intended to "f"?"'' ''^^J'^ executable file F7 and a chent object execut- 

enable the description concerning the stub method. The ^"^^ 

designator "Active" has been defined by an extension of Thus, in the process shown in FIG. 1, the server object 

C++ specifically for the purpose of carrying out the present executable file F7 is generated by an executable file gener- 
invention. A member function designated as "Active" is the 35 aling program 2 having a compiler and a linker from the 

member function corresponding to the stub method. In HG. resources which include the file f2 (Test_svc_proc.cc) 

1, a file Fl in which the first source code is described is describing the second source code, the server stub file F4 

represented by "Test.h". (TestStub.cc, TestStub.h) containing the stub method 

The second source code contains server object informa- tf^J^^^^'' server object, and the common stub file 
tion described in C++. Ilie second source code contains the 40 (TestEntry.h, TestMsg.h) which is commonly used by the 

portion of the server object information other than the object ^^^J^^ ^^^"S ^^e object mteraction. 

interaction information described in the first source code. At the same time, the client object executable file F8 is 

The second source code further contains, for example, a generated by an executable file generating program 3 having 

procedure for calling, from the stub method described by the a compiler and a linker from the resources which include the 
first source code, a method for generating a thread which 45 ^^e F3 (Test.cc) describing the third source code, the client 

performs a processing based on a received message. In FIG. stub file F5 (TestProxy.cc, TestProxy.h) containing the stub 

1, a file F2 describing the second source code is represented method description for the client object, and the common 

by "Tcst_svc_proc.cc". stub file F6 (TeslEntry.h, TestMsg.h) which is commonly 

The third source code contains client object information ^^ed by the objects taking part in the object interaction, 
described in C++. It is to be noted that the third source code 50 ^ detailed description will now be given of the stub 

includes the portion of the client object information other generator 1. 

than the object interaction information described in the first The stub generator 1 is designed to generate a stub method 

source code. Thus, the third code contains a description for very easily and with a high degree of versatility without 

implementing a main function, e.g., connection to an appro- using any interface definition language, by virtue of the use 
priate service, in the form of an application program. In FIG. 55 of the designator "Active". 

1, a file F3 in which the third code is described is represented More specifically, the stub generator 1 is a source code 

by "Test.cc". transformation program which is formed by using an objecl- 

The first source code is transformed by a stub generator 1 oriented programming technique, and is intended for gcn- 

inlo a source code described with C++ without the use of the crating a stub method to be employed in object interaction, 
above-mentioned designator "Active". In other words, the 60 The stub generator 1 performs transformation of source code 

stub generator 1 transforms the source code, such that the which describes a stub method with the help of the desig- 

member function designated by the designator "Active" is nator "Active" into source code which describes the stub 

described with C++ that has not been extended to enable the method in the C++ language without using such a designa- 

use of the designator "Active". Consequently, a stub method tor. More specifically, in the procedure shown in FIG. 1, the 
is generated which is described in the same programming 65 stub generator 1 serves to transform the file Fl (Test.h) 

language, i.e., C++, as those used for the description of the describing the stub method with the help of the designator 

second and third source codes. "Active" so as to generate the server stub file F4 (TestStub.h, 
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TesiStub.cc), the client stub file F5 (TestProxy.h, The input source code is analyzed by the analyzing 

TestProxy.cc) and the common stub file F6 (TesiEntry.h, section 4 in the described manner, whereby an intermediate 

TestMsg.h). expression is obtained. Then, the generating section 5 oper- 

As will be seen from FIG. 2, the stub generator 1 is atcs to generate the target source code from the intermediate 
composed mainly of an analyzing section 4 which analyses 5 expression produced by the analyzing section 4. More 

an input source code, and a generating section 5 which specifically, a code generating routine (CodeGenerate) 16, 

generates a stub method fi-om the analyzed source code. The which is included in the generating section 5 generates and 

analyzing section 4 divides the input source code into outputs the target source code, based on the syntax tree 

constituent elements to generate an intermediate expression information obtained as the result of the analysis performed 
of the program, while the generating section 5 generates a lO by the syntax analyzing routine 14. More specifically, the 

stub method from the intermediate expression generated by code generating routine 16 calls a code generating object 

the analyzing section 4. (CodeGenManage) 17. The code generating object 17 

The configuration of the analyzing section 4 corresponds »"*^»"'les a method for generating the target source code from 

to the programming language which describes the input the mtennediate expression obtamed through the analysis 
source code. Tlius, the analyzing section 4 has a different ^5 performed by the analyzing secUon 4. Thus, the target source 

configuration when a different programming language is ^ generated by the code generating object 17. 

used for describing the source code input to the stub gen- More specifically, the code generating object 17 generates 

erator 1. It is to be understood, however, that the analyzing and outputs the server stub file F4 (TestStub.h, TestStub.cc), 

section 4 generates the same intermediate expression regard- the client stub file F5 (TestProxy.h, TestProxy.cc) and the 
less of the type of the programming language. A common ^° common stub file F6 (TestEntry.h, TestMsg.h). These files 

generating section 5, therefore, can be used for different F4, F5 and F6 have been described in C++, without the use 

programming languages used for describing the source code of the designator "Active". 

input to the stub generator 1. The stub generator 1 is configured so as to register 

FIG. 2 shows, by way of example, the process performed predetermined pattern files F9 in the code generating object 

by the stub generator 1. An input processing routine 11 17. These pattern files F9 are switchable so that stub 

(Charlnput) receives the file Fl (Test.h) described with the methods corresponding to different program executing envi- 

C++ extended to use the designator "Active", The routine 11 ronments are generated, as will be understood from the 

removes null spaces and comments from the input source following description. 

code, so as to extract meaningful programming terms. In this In general, an application program is executed under a 

input processing routine 11, the designator "Active" which predetermined program executing environment which is 

is defined by extended C++ is also recognized as a reserved provided by the operating system. There are a variety of 

word. program executing environments. 

A sut)sequent routine, i.e., a term analyzing routine An operating system "Aperios" (registered trademark), 

(TokenAnalyze) 12, analyzes the terms extracted in the input for example, is designed to simultaneously provide a plu- 

processing routine 11 and produces a token stream in which rality of different program executing environments. Each of 

meaningful programming terms are arranged according to the program executing environments is referred to as a 

tokens which are units of logic. This term analyzing routine "meta space". More specifically, the operating system "Ape- 

also recognizes the designator "Active" that is defined by the rios" can simultaneously provide a meta space referred to as 

extended C++. an "mAV meta space" and a meta space referred to as an 

The input processing routine 11, as well as the term "mCOOP meta space". The mAV meta space is for executing 

analyzing routine 12, uses a symbol table managing object so-called proedural programs. An application program to be 

(SymbolManage) 13. The symbol table managing object 13 executed on the mAV meta space is described as a single 

has a data architecture referred to as a "symbol table" which object. On the other hand, the mCOOP meta space is used 
contains information concerning various constituent ele- 45 for object-oriented programs. In general, an application 

ments of the program. For instance, the symbol table stores, program to be executed on the meta space is constituted by 

as shown in FIG. 3, the information concerning the class a plurality of objects. 

designated by the designator "Active", including the name When the operating system "Aperios" is loaded on a 

of the class and the name of functions contained in the class device having a television (TV) function, the arrangement 
and their return values, as well as the names of the param- 50 may be such that an application program for displaying 

elersof the functions and the types of the parameters. Each moving images on the television is executed in the mAV 

function may employ two or more parameters. In such a meta space, while an application program, which imple- 

case, information registered in the table contains the names ments a graphical user interface (GUI) for controlling an 

and types of these parameters. operation panel through which operation instructions are 

The contents registered in the symbol table managing 55 input to the device, is executed on the mCOOP meta space, 

object 13 are dynamically changeable. That is to say, the The stub method employed in the application program 

contents can be altered as desired, in accordance with the executed on the mAV meta space is different from the stub 

stub method to be generated. method employed by the application program executed on 

Referring back to FIG. 2, a syntax analysis the mCOOP meta space, 
(SyntaxAnalyse) 14 is then executed to perform a syntax 60 It is necessary that the stub method generated by the stub 

analysis on the token stream produced as a result of the term generator 1 suits the program execution environment on 

analyzing routine 12. As a result of this analysis, so-called which the stub method is to be executed. More specifically, 

syntax tree information, indicative of the correlation the stub method of the application program to be executed 

between the tokens constituting the token stream, is gener- on the mAV space has to correctly function on the mAV meta 
ated and stored in the syntax tree object (TreeManage) 15. 65 space. Similarly, the stub method of the application program 

llie syntax tree information thus obtained constitutes part of to be executed on the mCOOP meta space has to correctly 

the intermediate expression described above. function on the mCOOP meta space. 
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In the stub generator 1 used in the described embodiment, As will be underetood from the foregoing description, the 

therefore, pattern files F9 corresponding to a plurality of present invention makes it possible to generate a stub 

different program execution environments can be registered method without the use of an interface definition language, 

in the code generating object 17, in order to make it possible by virtue of the use of the stub generator 1. This eliminates 

to generate stub methods for a plurality of different program 5 the necessity for the studying and learning of interface 

execution environments. In other words, pattern files F9 definition language which otherwise are necessary for when 

corresponding to the respective program execution environ- i^ose who are not familiar with interface definition Ian- 

ments are registered in the code generating object 17 for ^^^^ j jo form an appUcation program that uses a 

selective use m accordance with the program execution ^^^^ ^^^^^^ ^^^^^ -^^^^^-^^ , f^^jj-^^^^^ 

environment on which the desired stub method is to be fo,n,ationof an application program that u^s a stub method, 

executed, whereby the stub method is generated in accor- '^'^ * 

dance with each of a plurality of different program execution The stub generator 1 employed m the described 

environments embodiment, which enables generation of a stub method 

More specifically, referring to FIG. 2, pattern files F9 ^^.^^P interface definition language as stated 

describing infomiation necessary for generating stub meth- ^^^^f* P'°^^^'' advantage m that it eliminates the 

ods corresponding to the program execution environments P'^*^^^ encountered by the known art m regard to the 

are formed and registered iii the stub generator 1. prior to the ^^^^^^^y^ confirming coincidence between the interface 

ct,7w f #ko „™*t-^ fii«c presented by the portion described m an interface definition 

generation of a stub method. Upon receipt of the pattern files f . . 

.L . L . 1 . c^ • . laneuaee and the mterface of the portion described in a 

F9, the stub generator 1 activates a pattern file mput pro- & 6^ ^ lu lu n. ^ .„ " 

4* m *4 1 *Mo u- u . *u programming language such as C++. Thus, still another 

cessingroutme (Pattemlnput) 18 which accepts these pattern j ^ j, , i- . • . ^ • . 

files F9 and registers the accepted pattern files F9 as internal '° ".^^'"'^f /u T u ^l"" 8"""^'°', ^ 

information in the code generating object 17. It is to be noted ^ ""^'^ performed by the stub method in regard to con- 

* *u • * *• f 4U .7 £Li 1-n • *!. J firm atlon of the object interaction mterface IS greatly faciu- 

that the registration of the pattern files F9 in the code j 

generating object 17 is conducted with clear indication of ^ ^ ' 

the relations between the pattern files and the program „ ^ ^^^er advantage is that, since a reference is made to 

execution environments, i.e., to which one of the program ^ registered pattern file F9 corresponding to the program 

execution environments each pattern file corresponds. execution environment on which the stub method is to be 

TTie stub generator 1, when generating a stub method, ^xeoited the transformation of the source code can be 

makes a reference to one of the pattern files F9 that corre- conducted by using a smgle stub generator 1 commonly for 

sponds to the program execution environment on which the 3^ ^ P'^^^^^^^ P^^S^^"' execution environments, 

stub method to be generated is executed. Thus, a single stub ^ further advantage is that the stub generator 1 permits 

generator 1 can generate stub methods corresponding to a dynamic alteration of the stub method generating procedure, 

plurality of different program execution environments. virtue of the feature of registering a pattern file F9 

It is also to be understood that the registration of the corresponding to each of a plurality of different program 

pattern files F9 for different program execution environ- 35 execution environments. Therefore, the stub generator 1 can 

ments enables the stub generator 1 to dynamicaUy alter the generate, by altenng the contents of a pattern file F9, a stub 

procedure for generating the stub method. For instance, '"^^^^^ ^^^^h was not contemplated in the initial design of 

when it is desired to generate a stub method corresponding generator 1. 

to a new program execution environment, a pattern file F9 As will be understood from the foregoing description, the 
corresponding to the new program execution environment is 40 present invention provides a source code transformation 
input to the stub generator 1, so that the stub generator 1 process which enables generation of a stub method with high 
generates a stub method corresponding to the new program degrees of ease and versatility, as well as wide adaptability 
execution environment. Similarly, when an existing program to a variety of program execution environments, without 
execution environment has been updated, the pattern file F9 using any interface definition language, 
corresponding to this program execution environment is 45 Although the invention has been described through its 
modified correspondingly and registered in place of the preferred form, it is to be understood that the described 
existing pattern file F9. Consequently, the stub method is embodiment is only illustrative. For instance although the 
generated for the updated program execution environment. C++ has been specifically mentioned as the programming 
The source code inputted to the stub generator 1 is language which describes the source code, the present 
described by using the designator "Active" in a format 50 invention can equally be carried equally well by using 
which is common to different program execution another programming language. Further changes and modi- 
environments, i.e., with no dependency on the program fications may be imparted thereto without departing from the 
execution environment on which the stub method to be scope of the present invention which is limited solely by the 
generated is executed. Thus, the contents described in each appended claims, 
pattern file F9 include the information which is necessary for ss What is claimed is: 

transforming the source code described in the format com- 1- A source code transformation process, comprising the 

mon to a plurality of different program execution environ- steps of: 

ments into another source code corresponding to a selected inputting, as a first file, primary source code described 

program execution environment. with a first programming language which is both a 

Thus, the stub generator 1 used in this embodiment 60 non-interface-definition language and an extended ver- 

transforms, by referring to the registered pattern file F9, the sion of a second programming language, said source 

source code containing information of a stub method code containing information concerning a stub method 

described in a format common to a plurality of different to be used in an object interaction, said information 

program execution environments into another source code of being described in a format which is common to a 

a predetermined format corresponding to the program 65 plurality of different program execution environments; 

execution environment on which the stub method is to be inputting a server object information source code as a 

executed. second file containing a portion of server object infor- 
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mation other than object interaction information 
described in said primary source code; 

inputting a client object information source code as a third 
file containing a portion of client object information 
other than object interaction information described in 
said primary source code; 

transforming, by referring to registered information cor- 
responding to the program execution environment on 
which said method is to be executed, said primary 
source code into a secondary source code described 
with the second programming language in a predeter- 
mined format corresponding to the program execution 
environment on which said method is to be executed, 
wherein said transformation generates a fourth file 
which contains a stub method description for a server 
object, a fifth file containing a stub method description 
for a client object, and an include file which is to be 
commonly used by objects involved in the object 
interaction; and 

compiling said second, third, fourth, fifth and include 
files, and linking the results of said compilations, to 
thereby form a server object executable file and a client 
object executable file. 

2. The source code transformation process of claim 1, 
wherein each of said program execution environments is a 
respective type of meta space. 

3, The source code transformation process of claim 1, 
wherein said plurality of different program execution envi- 
ronments include a first meta space for executing procedural 
programs and a second meta space used for object-oriented 
programs. 

4. The source code transformation process of claim 1, 
wherein said first programming language is extended C++ 
and said second programming language is C++. 

5, A computer-readable recording medium, storing a 
source code transformation program that implements a pro- 
cess comprising the steps of: 

inputting, as a first file, primary source code described 
with a first programming language which is both a 
non -interface-definition language and an extended ver- 
sion of a second programming language, said source 
code containing information concerning a stub method 
to be used in an object interaction, said information 
being described in a format which is common to a 
plurality of different program execution environments; 

inputting a server object information source code as a 
second file containing a portion of server object infor- 
mation other than object interaction information 
described in said primary source code; 

inputting a client object information source code as a third 
file containing a portion of client object information 
other than object interaction information described in 
said primary source code; 

transforming, by referring to registered information cor- 
responding to the program execution environment on 
which said method is to be executed, said primary 
source code into a secondary source code described 
with the second programming language in a predeter- 
mined format corresponding to the program execution 
environment on which said method is to be executed, 
wherein said transformation generates a fourth file 
which contains a stub method description for a server 
object, a fifth file containing a stub method description 
for a client object, and an include file which is to be 
commonly used by objects involved in the object 
interaction; and 
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compiling said second, third, fourth, fifth and include 
files, and linking the results of said compilations, to 
thereby fonm a server object executable file and a client 
object executable file. 
5 6. The recording medium of claim 5, wherein each of said 
program execution environments is a respective type of meta 
space. 

7. The recording medium of claim 5, wherein said plu- 
rality of different program execution environments include a 

10 first meta space for executing procedural programs and a 
second meta space used for object-oriented programs. 

8. The recording medium of claim 5, wherein said first 
programming language is extended C++ and said second 
programming language is C++. 

35 9. A computer-readable recording medium, storing a 
program that implements a source code transformation pro- 
cess for generating stub methods used in object interactions, 
said process comprising the steps of: 

receiving, by a stub generator, a plurality of pattern files 
20 each corresponding to one of a plurality of program 
execution environments including at least a first meta 
space for executing procedural programs and a second 
meta space for executing object oriented programs; 
registering said pattern files as internal information of said 

stub generator; 
inputting a primary source code described with a first 
programming language which is an extended version of 
a second programming language, said first and second 
programming languages each being non-interface- 
definition languages, said source code containing infor- 
mation concerning a sUib method to be used in an 
object interaction, and said information being described 
in a format which is common to a plurality of different 
program execution environments; and 
transforming, by said stub generator referring to one of 
said registered pattern files corresponding to the pro- 
gram execution environment on which said stub 
method is to be executed, said primary source code into 
a secondary source code described with the second 
programming language in a predetermined format cor- 
responding to the program execution environment on 
which said stub method is to be executed; 
whereby said stub generator generates a plurality of stub 
methods corresponding to a plurality of program execu- 
tion environments, respectively 
10. A source code traosfonmation process for generating 
stub methods used in object interactions, comprising the 
steps of: 

5Q receiving, by a stub generator, a plurality of pattern files 
each corresponding to one of a plurality of program 
execution environments including at least a first meta 
space for executing procedural programs and a second 
meta space for executing object oriented programs; 

55 registering said pattern files as internal information of said 
stub generator; 
inputting a primary source code described with a first 
programming language which is an extended version of 
a second programming language, said first and second 

60 programming languages each being non-interface- 
definition languages, said source code containing infor- 
mation concerning a stub method to be used in an 
object interaction, and said information being described 
in a format which is common to a plurality of different 

65 program execution environments; and 

transforming, by said stub generator referring to one of 
said registered pattern files corresponding to the pro- 
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gram execution environment on which said stub 
method is to be executed, said primary source code into 
a secondary source code described with the second 
programming language in a predetermined format cor- 
responding to the program execution environment on 5 
which said stub method is to be executed; 
whereby said stub generator generates a plurality of stub 
methods corresponding to a plurality of program execu- 
tion environments, respectively. 
U. The source, code transformation process of claim 10, 
wherein said first programming language is extended C++ 
and said second programming language is C++, 

12. "llie source code transformation process of claim 10 
wherein said transformation generates a fourth file which 
contains a stub method description for a server object, a fifth ^5 
file containing a stub method description for a client object, 
and an include file which is to be commonly used by objects 
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involved in the object interaction, and said process further 
comprising the steps of: 

inputting a server object information source code as a 
second file containing a portion of server object infor- 
mation other than object interaction information 
described in said primary source code; 

inputting a client object information source code as a third 
file containing a portion of client object information 
other than object interaction information described in 
said primary source code; 

compiling said second, third, fourth, fifth and include 
files, and linking the results of said compilations, to 
thereby form a server object executable file and a chent 
object executable file. 
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[57] ABSTRACT 

A system for loading an applet and its associated use rights 
into a smart card having other applets with associated use 
rights with values that change as the application is used is 
provided that stores, remotely from said smart card, an 
applet and use rights with a predetermined initial value, 
associated with the applet, and has a smart card having a 
processing unit, and a memory unit, the memory unit being 
connected to the processing unit and storing a second 
application having use rights. The smart card may be con- 
nected to said remote storage means, and the application, 
having use rights with a predetermined value, may be loaded 
from said remote storage means into said smart card. A smart 
card is also provided having a processor for executing an 
application, a memory, connected to the processor, for 
storing multiple applications, including a first application 
having first use rights and having first values associated with 
the first use rights, the first value changing from a prede- 
termined initial value with use of the first use rights, a 
system for loading in the smart card a second application 
from a remote location over an interface, the second appli- 
cation having second use rights, a system for storing said 
second application into said memory in said smart card, and 
a system for changing the use rights of said first application 
and said second application. A method of replenishing the 
use rights in a smart card is also provided. 

12 Claims, 7 Drawing Sheets 
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SYSTEM AND METHOD FOR LOADING 
APPLICATIONS ONTO A SMART CARD 

BACKGROUND OF THE INVENTION 

lliis invention relates generally to secure portable tokens, 
such as smart cards and in particular to smart cards having 
reloadable applications. 

As is well known, a smart card may be a plastic, credit 
card-sized card containing a semiconductor chip, such as a 
microprocessor built into the smart card so that it may 
execute some simple application programs, which may be 
referred to as applets. Some examples of the applications in 
a smart card include security and authentication, information 
storage and retrieval, and credit and debit operations for 
managing value accounts, such as prepaid phone time and 
debit accounts. Each value account application on the smart 
card has a particular type of use rights associated with the 
application. For example, a prepaid phone time application 
may have a predetermined number of prepaid phone minutes 
that are used up as phone calls are made with the card, and 
a prepaid public transit account may have an initial preset 
monetary values which is debited with each use of public 
transportation. To store and execute these applets, these 
smart cards have a built-in memory and processor. In order 
to ensure the security of the use rights on these smart cards, 
only the processor within the smart card may ordinarily alter 
the value of the use rights, and only after an authorization 
sequence has been successfully conducted. The network in 
which the smart card is being used does not have any direct 
access to the memory of the smart card nor to the use rights 
of any application. 

There are generally two different types of smart cards, i.e., 
disposable smart cards and permanent, non-disposable smart 
cards. A disposable smart card may have a rudimentary 
semiconductor chip embedded within the smart card and 
may have a limited amount of memory and some hardwired 
logic. The disposable smart cards may have a predetermined 
initial amount of prepaid use rights or other value stored in 
the memory of the smart card established when the smart 
card is manufactured. The prepaid use rights are then 
depleted as the smart card is used. A prepaid phone card or 
a subway fare card are examples of disposable smart cards 
because these smart cards are thrown away after the prepaid 
use rights are depleted. These disposable smart cards are 
inexpensive because of the rudimentary semiconductor chip, 
but they have limited utility since their stored value cannot 
be replenished, and other applications cannot be installed on 
them. Due to the limited memory and processing power, 
these disposable smart cards also cannot execute sophisli- 
caled cryptographic algorithms, which means that these 
disposable smart cards are less secure. 

The non-disposable, permanent smart cards may have a 
more complex semiconductor chip embedded within the 
card, and may have a programmable micro-controller and an 
expanded memory. The memory may store one or more 
applets that have separate predetermined amounts of use 
rights for different functions. Importantly, these permanent 
smart cards have use rights that may be replenished so that 
the permanent smart card need not be discarded once the use 
rights are depleted. Examples of these permanent smart 
cards include banking cards according to the Europay/ 
MastercardA^isa standard, and pay television access control 
cards. These permanent smart cards have more memory for 
storage of multiple applets and the use rights on the smart 
card may be separately and independently replenished. 
However, these permanent smart cards are also more expen- 
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sive due to the additional memory and the microcontroller, 
and the replenishment can only be performed by the card 
issuer. 

Initially, many companies issued disposable smart cards 

5 due to the lower initial investment. However, due to the 
security concerns of these disposable smart cards and the 
limited applications that may be run on these disposable 
cards, the current trend is to use permanent smart cards 
because several applications may be loaded onto a single 

^0 permanent smart card. The permanent smart card is also 
more secure because more sophisticated cryptographic tech- 
niques may be used. 

Most conventional permanent smart cards may have a 
memory unit that may include a read only memory (ROM), 
a random access memory (RAM), and a non-volatile 
memory (NVM). The NVM may be, for example, a flash 
memory such as a flash electrically erasable programmable 
read only memory (Flash EEPROM), or a EEPROM. These 
permanent smart cards receive all of their power from the 
terminal to which they are connected during use. As a 
consequence, the RAM, which is volatile memory, may be 
used only as a scratch pad memory for simple computations 
that do not need to be stored. The ROM, which is permanent, 
may store the operating system (OS) of the smart card and 
other programs which do not need to be updated or changed, 
such as certain permanent applets, l^e NVM may store 
certain applets and the use rights secrets or values associated 
with all applications in the smart card. These conventional 
permanent smart cards may have multiple applications that 
reside in the memory of the smart card. 

Some conventional permanent smart cards have fixed 
application programs that are stored in the ROM at the time 
that the smart card is manufactured. These smart cards do 
not permit any applications to be stored in the NVM due to 
security concerns. The progranris that are stored in the ROM 
cannot be altered. The applications for these ROM -based 
smart cards, however, take a great amount of time to develop 
because the application must be developed and then be hard 
wired into the ROM. In addition, these fixed applications are 
not changeable or removable. 

To solve the problems of a fixed application in the ROM, 
some current smart cards permit applications to be stored in 
the NVM. However, handling of applications and their 

45 associated use rights in the NVM of the smart card poses 
several problems. 

First, there is a security problem since access to the 
application within the NVM may also permit access, by a 
clever individual, to the other applications within the NVM 

50 unless carefully controlled. In addition, a clever person may 
figure out a way to replenish his use rights illegally as they 
are also stored in the NVM. This is an especially large 
problem for banks that want to issue debit or electronic purse 
cards since a person could replenish the money available on 

55 the smart card without debiting his bank account. For a bank, 
it is desirable that no one, but the bank have access to the use 
rights within the smart card. This means that the use rights 
of any applet on a smart card may only be replenished by the 
card issuer, such as the bank, which may be inconvenient. In 

60 addition, any other company with applets on that smart card 
must have a relationship with the card issuer. 

Second, the replenishing of the use rights of an applet in 
the smart card may be slow because there must be a number 
of security procedures that must be followed when use rights 

65 are being changed. For example, there must be several 
authentication procedures to ensure that no illegal activities 
are occurring. 
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Third, since each type of application may have a different 
type of use rights in various different units, such as phone 
minutes in time units versus cash in monetary units, each 
different application will probably require a different use 
rights reload procedure. For example, a use rights reload 
procedure for phone minutes may not be able to replenish 
the cash of a debit account on a smart card. Thus, procedures 
that loads use rights into the smart card must be duplicated. 

To limit access to these use right values, conventional 
permanent smart cards have done several different things. 
First, some conventional permanent smart cards have con- 
trolled the access to certain areas of memory, known as 
memory zones, so that these memory zones are write-once 
areas. Other conventional permanent smart cards use a data 
dictionary, which keeps track of the memory areas in which 
each of the application must reside. Thus, some sort a 
memory management system must constantly verify that 
none of the applications are doing illegal activities. 

In summary, some conventional permanent smart cards do 
not allow any applications to reside in the NVM to reduce 
security risks. Other conventional permanent smart cards 
have systems for replenishing the use rights of an applica- 
tion contained on a smart card, but limit this capability to the 
issuer of the smart card, and require separate loading pro- 
cedures for each applet. None of these conventional smart 
card systems provide a system for loading an entire appli- 
cation of any type, including the use rights, into the memory 
of a permanent smart card. Accordingly, conventional smart 
cards cannot store disposable applications, such as a prepaid 
telephone time applet, because there is no method for 
removing the disposable application once it is depleted or 
replacing the disposable applet with a new applet. Thus, in 
conventional smart cards, these depleted disposable appli- 
cations would remain in the smart card taking up valuable 
memory space. For this reason, most permanent smart cards 
today do not have any ability to handle disposable applica- 
tions. 

ITius, there is a need for a system and method for 
universally reloading different types of use rights in multiple 
application smart cards which avoid these and other prob- 
lems of known devices, and it is to this end that the present 
invention is directed. 

SUMMARY OF THE INVENTION 

The invention provides a smart card, as well as a system 
and method for loading applications into the memory of a 
smart card which may load any type of application and its 
associated use rights, wherein the use rights may have any 
type of units. In addition, the system may load one or more 
disposable applications onto a permanent smart card since 
those disposable applications, once depleted, may be 
replaced with a new applet. 

The invention also provides an applet loading system for 
a smart card wherein the use rights associated with an applet 
may be replenished by reloading the applet and the use rights 
into the memory of the smart card. The system for loading 
applications into a smart card may be universal so that a 
single loading system may be used for a variety of applica- 
tions. In accordance with the invention, a system and 
method for reloading applications within a smart card is 
provided wherein the system may have a storage, remotely 
from said smart card, that stores an applet and use rights with 
a predetermined initial value, associated with the applet, and 
has a smart card having a processing unit, and a memory 
unit, the memory unit being connected to the processing unit 
and storing a second application having use rights. The 
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smart card may be connected to said remote storage means, 
and the application, having use rights with a predetermined 
value, may be loaded from said remote storage means into 
said smart card. A smart card is also provided having a 

5 processor for executing an application, a memory, connected 
to the processor, for storing multiple applications, including 
a first application having first use rights and having first 
values associated with the first use rights, the first value 
changing from a predetermined initial value with use of the 

10 first use rights, a system for loading in the smart card a 
second application from a remote location over an interface, 
the second application having second use rights, a system for 
storing said second application into said memory in said 
smart card, and a system for changing the use rights of said 

15 first application and said second application. A method of 
replenishing the use rights in a smart card is also provided. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a smart card with which the 
20 invention may be employed; 

FIG. 2 is a block diagram depicting the creation of a 
program that may run on the smart card of FIG. 1; 

FIG. 3 is a block diagram of the memory organization of 
25 the smart card of FIG. 1; 

FIG. 4 is a block diagram of a preferred system for 
reloading applications onto a smart card; 

FIG. 5 is a block diagram of a first embodiment of a 
method in accordance with the invention of reloading an 
30 application into a smart card; 

FIG. 6 is a block diagram of a second embodiment of a 
method in accordance with the invention of reloading an 
application into a smart card; 

FIG. 7 is a block diagram of a third embodiment of a 
method in accordance with the invention of reloading an 
application into a smart card; 

FIG. 8 is a flowchart of a method of debiting use rights in 
a smart card; and 
40 FIG. 9 is a flowchart of a method of replenishing the use 
rights of an application within a smart card in accordance 
with the invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

45 

'llie invention is particularly applicable to a system and 
method for reloading applications having use rights onto a 
permanent smart card so that the use rights of the application 
may be replenished when they have been depleted. It is in 

50 this context that the invention will be described. It will be 
appreciated, however, that the system and method in accor- 
dance with the invention has greater utility. 

FIG. 1 is a block diagram of a smart card 20, also known 
as a token, of the type with which the invention may be 

55 employed. The smart card may be used in connection with 
the system and method of loading applications into a smart 
card in accordance with the invention. The smart card may 
preferably be a permanent smart card, but may also be a 
disposable smart card. This smart card 20 may have a 

60 processor or CPU 22 and a memory 24. The memory may 
comprise a read only memory (ROM) 26, a random access 
memory (RAM) 28, and a non-volatile memory (NVM) 30. 
The NVM may be any type of writable nonvolatile memory, 
such as an electrically erasable, programmable read only 

65 memory (EEPROM), a battery backed RAM, or a flash 
memory, that can retain stored data when no electrical power 
is supplied to the memory. The ROM may preferably store 
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the operating system (OS) which controls the operatioD of FIG. 3 is a block diagram of the memory organization of 

the CPU of the smart card, and the RAM may be used as a the smart card 20 that may include a system for loading 

temporary scratchpad memory. Because the smart card applets into the smart card in accordance with the invention, 

receives its electrical power from the terminal into which it The memory 24 of the smart card, which may include the 

is inserted, as described below, all of the contents of the 5 ROM and NVM, may be logically organized into an OS 

RAM will be lost when the smart card is removed from the layer 50, an executive layer 52, and an application layer 54, 

terminal. The NVM may preferably be used to store one or The OS layer may contain the most basic operating software, 

more applications which may be referred to as applets due such as a cryptographic library 56, and an interpreter 58. 

to the small size of the actual program code. Each of these These programs are permanent and may be stored in the 

applets may have associated use rights which are specific to ROM. The cryptographic library may be used for authenti- 

the applet. Other permanent applications that do not change. eating access to the smart card, as described above. The 

such as a credit/debit program, may be stored in the ROM. interpreter 58, as described above, may be used to prevent an 

llie processor 22 controls the operation of the smart card. applet from directly accessing the hardware of the smart 

The processor may be connected to all of the memories card. 

within the memory system 24. Since there are use rights ^5 The executive layer 52 may contain, for example, an 

associated with an application, there is a need to make the application launcher 60, a conditional application loader 62 

smart card secure to prevent theft or alteration of the use in accordance with the invention, and other OS sub-systems 

rights. To accomplish this security, the processor is the only 64. The application launcher receives a request to access an 

system that is capable of accessing any of the memories. application, and after appropriate authentication, launches 

There is no direct access to any of the memories from 20 controls the applet, 'llie conditional application loader 

outside of the smart card. In addition, any outside access to 62 controls the loading of an appHcation, or applet, into the 

the memories of the smart card must be conducted through NVM of the smart card. The application loader may verify 

an input/output (I/O) line 32 that is connected to the pro- that the remote system desiring to load an applet into the 

cessor 22. The smart card may also have more than one I/O smart card has the appropriate authority, and then may 

line provided that access to each I/O line is carefully 25 perform the necessary operations, as described in more 

controlled so that there is no direct access to any of the detail below, to load the applet into the NVM of the smart 

memories from outside of the smart card. Thus, the proces- card. 

sor may authenticate and validate incoming requests prior to The apphcation layer 54 may contain a permanent appli- 

making any change in the use rights of an application stored cation 66 and one or more disposable applications 68 having 

in the smart card, and may prevent unwanted or illegal 30 associated use rights. The permanent application may be 

attempts to decrease the use rights of an application. This stored in the ROM since it is permanent and may be a 

authentication and validation may be conducted using cryp- credit/debit system that performs all of credit and debit 

tographic systems, such as public key encryption, or any transactions for all of the disposable applications having use 

other security system. Now, a preferred system for generat- rights within the smart card. The credit/debit system may 

ing applets for a smart card will be briefly described. 35 operate with any type of use rights so that only a single 

FIG. 2 is a block diagram showing the architecture of the credit/debit application is needed for each smart card. In this 

smart card and the manner in which an applet is generated manner, the use rights of any applet within the smart card 

for the smart card. To provide suflBcient security for the may be changed by the permanent credit/debit application 

smart card, a preferred embodiment of a smart card may 66. In a preferred embodiment of the invention, the loader 62 

have a virtual machine 40 contained within the smart card. 40 and the credit/debit application 66 may be a single program 

The virtual machine is comprised of a software interpreter since both programs operate on all of the applets having use 

42 running on the hardware processor 22. The interpreter is rights. For example, an applet with use rights needs the 

a piece of software that acts as an interface between the credit/debit application to authorize the reload if the applet 

hardware processor and the applets. In this manner, the when the use rights have been depleted, as described below, 

applets run through the interpreter so that the applets do not 45 The disposable application 68 may be any type of appli- 

have any direct access to the hardware of the smart card. cation or applet with a limited lifetime, as defined by a 

Thus, the interpreter may verify that none of the applets are certain number of use rights, such as a predetermined 

performing illegal operations. Instead of a complete inter- number of telephone call minutes, a predetermined amount 

preter and virtual machine, the smart card may have a of money, or a predetermined number of store credits. As 

command dispatcher to control the access of the applets to 50 described below in more detail, conventional smart cards 

various portions of the smart card. The dispatcher may that replenished the use rights of a particular application 

control access of the applets to the hardware by preventing require a separate use rights loading system for each differ- 

the applets from receiving any access until an authentication ent application because the use rights of each application 

check has been completed. A command dispatcher may be may require different handling and security. For example, 

considered to be a reduced version of a general interpreter, 55 replenishing a certain number of store frequent buyer points 

and the command dispatcher interprets commands received onto a smart card may be different than replenishing the cash 

from the applications instead of interpreting the entirety of value of a debit applet, such as a point-of-sale applet, in the 

the code of the applications, smart card. In addition, in order to replenish the use rights 

To execute an applet on an interpreter, as shown, source of any applet, the smart card needed to be physically 

code 46 of an applet is compiled into a byte code 48. The 60 connected with or returned to the card issuer since only the 

byte code may then be executed by any interpreter on any card issuer had the authority the alter the use rights for an 

smart card. The details of the architecture of the preferred applet. Therefore, every company who may have an applet 

smart card are set forth in more detail in PCT Application on the smart card, must have a relationship with the card 

No. PCT/NL95/00055, published as International Publica- issuer so that the card issuer can replenish the use rights of 

tion No. WO 95/22126. which is incorporated herein by 65 that applet. 

reference, llie organization of programs within the memory Significantly, however, the smart card in accordance with 

of the smart card will now be described. the invention may have a universal applet loader that may 
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delete and then reload an entire applet instead of establishing 
a connection between the smart card and the applet issuer 
who then just reloads the use rights. Reloading the entire 
applet into the smart card means that the loader does not 
have to be specialized to handle the muhiplicity of different 5 
types of use rights which could be present in the smart card 
since the entire applet, including the use righLs, is being 
reloaded into the smart card. The loading of an applet into 
a smart card to permit the replenishment of the use rights of 
an applet will be described in more detail below. 

The universal loader 62 in accordance with the invention 
may also be used to load new applets into a smart card, 
provided that the smart card has available memory. In 
addition, the universal loader may also permit an applet with 
depleted use rights to be deleted from the memory of the 
smart card and replaced with a new different application 
having refreshed use rights. Each of these operations will be 
described in more detail below. A preferred system, external 
to the smart card, for loading applets having use rights, into 
the smart card will now be described. 

no. 4 is a block diagram showing a system in accordance 20 
with the invention for loading an applet having use rights 
into a smart card. The system may include the smart card 20, 
a terminal 80, and a server 82. The smart card 20 is described 
above with reference to FIGS. 1-3. The terminal may be 
operated by the smart card issuer, or by some other entity, 25 
such as a bank. The terminal may be a bank ATM teller, a 
terminal in a bank or a home computer system. The server 
may be maintained by a bank or the issuer of the smart card, 
and may contain downloadable applets. The connection 
between the terminal and the server may be any conven- 30 
tional network, such as the usual connection between ATM 
machines across the world. 

As described above, the smart card may have the proces- 
sor 22, the OS layer 50 and the executive layer 52 stored in 
the ROM 26, and the applications layer 54 stored in the 35 
NVM 30. In addition, the smart card may have an interface 
system 86 that may connect the smart card to the terminal 80 
using a corresponding interface 88. A second interface 90 
may connect the terminal to the server 82 via an interface 92. 
Thus, the smart card may be connected, through the 40 
terminal, to the server. A preferred method of loading an 
application into the smart card will now be described. 

When the smart card is connected to the terminal, the 
processor 22, using the loader 62, verifies the authenticity of 
the terminal and of the server. The terminal and the server 45 
may also verify the authenticity of the smart card. For 
example, when the smart card is connected to the terminal, 
the user may enter a personal identification number (PIN) 
that may be verified by the server. As another example, the 
server may send a coded word that must be correctly 50 
answered by the smart card. If the server and the smart card 
authenticate each other, then the universal loader 62 within 
the smart card begins the loading process. The applets stored 
on the server, regardless of the type of UvSe rights, may all 
have a common structure so that the universal loader does 55 
not have to distinguish between different types of applets 
except to identify which one(s) to load. As shown, the NVM 
30 may currently store the permanent credit/debit applica- 
tion 66, and an existing first applet 94 with use rights. After 
the loading operation, as described below, the NVM 60 
memory may also have a second new applet 96 with use 
rights. In the smart card shown, the use rights of the first 
applet 94 have been depleted. Therefore, a new copy of the 
applet 98 with refreshed use rights, located on the server 82, 
may be loaded into the NVM of the smart card, 'llie applet 65 
98 with refreshed use rights replaces the original applet 94 
with depleted use rights. 
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In addition to the replenishment of use rights, a new 100 
applet having use rights may be loaded into the smart card 
20 from the server 82 in a similar manner. Therefore, after 
the load process is complete, the smart card may have a first 
applet with replenished use rights, and the new second 
applet 96 with predetermined use rights. As an example, a 
smart card that has a telephone call applet with depleted use 
rights may have a new telephone call applet with refreshed 
use rights as well as a debit applet with a predetermined 
value, e.g., SlOO, loaded onto the smart card. The connec- 
tions between the terminal 80 and the server 82 may be 
conventional network system that may be used for home 
banking and the like. Several examples of loading applets 
into a smart card, in accordance with the invention, will now 
be described. 

As described above, conventional smart cards replenish 
the use rights of an applet by reloading new use rights into 
an applet on the smart card. The problems with reloading the 
use rights of an applet into a smart card have been described 
above. Now, several examples of the operation of the applet 
loading system in accordance with the invention will be 
described. 

FIG. 5 is a block diagram of the loading system in 
accordance with the invention being used to replenish the 
use rights of an applet within a smart card. As shown, the 
smart card 20 may have, for example, a first applet 102, a 
second applet 104, and a third applet 106. In this example, 
the first and third applets have use rights remaining, whereas 
the second applet needs to have its use rights replenished. In 
accordance with the invention, a new second applet 108 with 
replenished use rights is loaded into the smart card 20 and 
replaces the old second applet 104. Thus, after the loading 
process, the smart card may have a first applet 102, a third 
applet 106, and a new second applet 108 with replenished 
use rights. As shown, only the second applet is affected by 
the loading process. As described above, since the entire 
applet is loaded back into the smart card, the type of the use 
right of the applet is irrelevant, and the loading system may 
reload any type of applet within the smart card regardless of 
the type of use rights that the applet may have. 

FIG. 6 is a block diagram of the loading system in 
accordance with the invention being used to load a dispos- 
able application onto an existing smart card. As shown, the 
smart card 20 may have a first applet 102. In addition, at a 
remote system 112, a disposable applet 114 may be stored. 
The disposable applet may be loaded into the smart card 20 
so that the smart card may contain the first applet 102 and 
the new disposable applet 114. The disposable applets may 
be easily loaded into the smart card. In addition, once the use 
rights of the disposable applet are exhausted, the disposable 
applet may be replaced, using the loading method in accor- 
dance with the invention, with a new applet having new use 
rights. 

For example, a user may take a trip to a foreign country 
and desire some local currency to be placed on the smart 
card so that he docs not have to carry any cash. At the end 
of the trip, the user does not want to keep the foreign 
currency applet since he will not have any further need for 
it. Thus, the invention enables the foreign currency applet to 
be replaced by, for example, a prepaid telephone call applet. 

FIG. 7 is a block diagram of the loading system in 
accordance with the invention being used to replenish the 
use rights of an applet in a smart card. In this example, the 
smart card 20 has a single applet 116 with use rights. After 
some time, the use rights of the applet have been depleted. 
In accordance with the invention, the applet 116 may be 
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replaced by a new applet 120 that has the same fiiQctions as 
the old applet, but has replenished use rights. 

The invention, as shown, is not limited to any particular 
number of applets and may by used to replenish the use 
rights of as few as a single applet or to replenish the use 
rights multiple applets. The invention may also be used to 
load and replace a single disposable applet onto a smart card. 
A method of debiting use rights in a smart card will now be 
described. 

FIG. 8 is flowchart of a method 200 of debiting use rights 
in a smart card. First in step 202, an applet within the smart 
card may be selected. For example, when a smart card is 
placed into a telephone terminal, then the applet with the 
telephone use rights may be selected by the terminal. In 
order to select the applet, the smart card may verify that the 
terminal has the proper authority to access that particular 
applet. Then, at step 204, the smart card receives an appli- 
cation selection command from the terminal, for example. If 
the application selected is not initialized or present in the 
smart card, the method ends in step 206. If a valid applica- 
tion is selected, then in step 208, after a debit use rights 
command is issued, the smart card receives a debit use rights 
command at step 208. If the use rights have been exhausted 
already, then in step 210, the debit fails, and in step 212, the 
use rights of the applet may be replenished, as described 
below. If a valid debit command is received, then in step 
214, the decreased use rights of the applet are calculated and 
stored in the memory of the smart card. Then, if there are 
additional debits for the applet, the method loops to step 208, 
otherwise the method ends at step 216. The method of 
replenishing the use rights for an applet on the smart card in 
accordance with the invention will now be described. 

FIG. 9 is a flowchart of the step 212 of FIG. 8, for 
replenishing the use rights of the applet in accordance with 
the invention. The applet may be selected because it has 
expended its use rights or because the user selects a par- 
ticular applet. As described above, the universal loader can 
load any type of applet with any type of use rights from the 
server to the memory of the smart card. In addition, since the 
loader can load any type of applet, it is not necessary to get 
the use rights of the applet reloaded by the card issuer. Thus, 
the universal loader permits a greater amount of flexibility. 

Once any of the applet with the associated use rights has 
been selected, at step 230, the smart card verifies the 
authenticity of the provider, such as the server, of the applet. 
If the authentication fails, then the method ends at step 232. 
If the authentication is successful, then in step 234, the 
provider, with the help of the loader, loads the applet into the 
NVM of the smart card. 

Typically, authentication of the applet code may be 
achieved by the smart card through the verification of a 
digital signature, a cryptographic check sum or a predeter- 
mined hash value. In step 236, the smart card verifies the 
authenticity of the program code of the applet to detect 
viruses, and the like. In step 238, if the authentication of the 
applet code fails, then the applet code is deleted from the 
memory of the smart card. 

The next step is an optional step that is not required in 
order to load an application into a smart card in accordance 
with the invention. This step requires a smart card with a 
larger amount of memory. In this optional step 240, the 
smart card may perform static type checking and a syntax 
check of the code of the applet. If this check fails, then in 
step 242, the applet code is deleted from the memory of the 
smart card. In the last step 244, the smart card initializes the 
code of the applet so that the use rights of the applet may be 
debited, as described above with reference to FIG. 8. 
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While the foregoing has been with reference to a particu- 
lar embodiment of the invention, it will be appreciated by 
those skilled in the art that changes in this embodiment may 
be made without departing from the principles and spirit of 
the invention, the scope of which is defined by the appended 
claims. 

We claim: 

1. A system for loading an application and its associated 
use rights into a smart card having other applications, some 
of the other applications with associated use rights that have 
values that change as the application is used, the system 
comprising: 

means for storing, remotely from said smart card, an 
application and use rights with a predetermined initial 
value, associated with the application; 

said smart card having a processing unit, a memory unit 
for receiving applications having different use rights, 
the memory unit being connected to the processing unit 
and storing a second application having associated use 
rights; 

means for connecting said smart card to said remote 

storage means; and 
means for loading said application, having use rights with 

a predetermined value, from said remote storage means 

into said smart card. 

2. The system of claim 1, wherein the use rights have a 
refreshed state and a depleted state, the use rights of the 
second application being depleted and the use rights of the 
application being refreshed, and further comprising means 
for replacing said second application stored in the memory 
with said application at the remote storage means so that the 
use rights of the application in the memory are replenished. 

3. The system of claim 2, wherein the connecting means 
further comprises means for verifying the authority of the 
remote storage means to load an application into the 
memory of the smart card. 

4. Smart card apparatus for loading an application having 
use rights with values which meter use of the application, the 
smart card comprising: 

a processor for executing an application; 

a memory, connected to the processor, for storing multiple 
apphcations, including a first application having first 
use rights and having first values associated with the 
first use rights, the first value changing from a prede- 
termined initial value with use of the first use rights; 

an interface enabling the processor of said smart card to 
communicate with a remote location; 

means for receiving, in the smart card, applications hav- 
ing different use rights, the applications including the 
first application and a second application from said 
remote location over said interface, the second appli- 
cation having second use rights; and 

means for storing said second application into said 
memory in said smart card. 

5. The smart card apparatus of claim 4 further comprising 
means for replacing said first application stored in the 
memory with said second application from said remote 
location so that the use rights of the application in the 
memory are replenished. 

6. The smart card apparatus of claim 5, wherein the 
receiving means further comprises means for verifying the 
authority of the remote location to load an application into 
the memory of the smart card. 

7. A method of replenishing use rights in an application 
stored in a smart card, the use rights having a refreshed state 
and a depleted state and being depleted with use of the 
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application, the smart card tiaving a processor and a memory 
for storing the application, the method comprising: 
connecting a smart card having a first application with use 
rights in a depleted state to a communications system, 
the communications system being connected to a sys- 
tem remotely located from said smart card, the system 
storing a second application having equivalent use 
rights to the first use rights, the equivalent use rights 
having a refreshed state; 
verifying in the card that said remote storage system has 
the authority to replace the first application in the smart 
card; and 

replacing the first application in said memory with said 
second application having refreshed use rights so that 
the use rights of the application located within the 
memory of the smart card are replenished. 

8. The method of claim 7, wherein replacing further 
comprises deleting said first application from said memory 
of said smart card, and loading said second application 
having refreshed use rights from said remote storage loca- 
tion into said memory of said smart card so that the use 
rights of the application located within the memory of the 
smart card are replenished. 

9. A method of loading an application into a smart card, 
the application having use rights with a refreshed state and 
a depleted state and being depleted with use of the 
application, the smart card having a processor and a memory 
for storing the application, the method comprising: 

connecting a smart card having a first application with use 
rights to a communications system, the communica- 
tions system being connected to a system remotely 
located from said smart card, the system storing a 
second application having use rights; 

verifying in the smart card that said remote storage system 
has the authority to load the second application into the 
smart card; and 


10 


15 


loading said second application having refreshed use 
rights into the memory of the smart card so that the 
second application may be used. 

10. The method of claim 9, wherein the first application 
5 has depleted use rights, the second application having 

refreshed equivalent use rights to the first application, and 
wherein the loading comprises replacing the first application 
in said memory with said second application having 
refreshed use rights so that the use rights of the application 
located within the memory of the smart card are replenished. 

11. Smart card apparatus for loading an application hav- 
ing use rights with values which meter use of the 
application, the smart card comprising: 

a processor for executing an application; 
a memory, connected to the processor, for storing multiple 
applications, including a first application having first 
use rights and having first values associated with the 
first use rights, the first value changing from a prede- 
termined initial value with use of the first use rights; 
means for loading, into the smart card, applications hav- 
ing different use rights, the applications including a first 
application and a second application from a remote 
location over an interface, the second application hav- 
ing second use rights; 
means for storing said second application into said 
25 memory in said smart card; and 

means for changing the use rights of said first application 
and said second application. 

12. The smart card apparatus of claim 11, where said 
second application has equivalent use rights to the first use 

30 rights, the equivalent use rights having a refreshed state, and 
wherein storing means further comprises means for replac- 
ing the first application in said memory with said second 
application having refreshed use rights so that the use rights 
of the application located within the memory of the smart 

35 card are replenished. 
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[57] ABSTRACT 

A method of writing data to non-volatile memory such as 
electrically erasable programmable read only memory 
(EEPROM) in a smart card provides a write status region of 
EEPROM which is examined on each reset of Che card. If the 
preceding write operation was unsuccessful, perhaps 
because of deliberate manipulation of the card, a recovery 
procedure is in^lemented. If recovery is successful, the card 
operation can be run. Otherwise the card is unusable. 
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TAMPER PROOF SECURITY MEASURE IN 
DATA WRITING TO NON-VOLATBLE 
MEMORY 

BACKGROUND OF THE INVENnON 

1. Held of the laventioD 

The invention relates to the writiiig of data to non-volatile 
memory. Non-volatile memory is memory which retains 
data without electrical power being maiotained. In 
paiticular, the invention rdates to the writing of data to 
memory in transportable integrated circuit devices which are 
used in conjunction with terminal devices with which they 
are temporarily coupled for data input and output An 
exan^e of such a transportable device is the integrated 
drctiit card (ICC), olhenvise known as a ^smart card". 

2. Discussion of Prior Art 

Smart cards are coupled by means of an interface to a 
tcnninal device whereby power, clock signals, a reset signal 
and serial data signals may be applied to the card. Generally 
the interface incorporates a set of electrical contacts for 
direct temporary electrical connection. However, contactless 
interfaces employing electromagnetic induction techniques 
for the application of power have been proposed. In such an 
arrangement dock, reset and data signals may be coupled 
dectromagnetically or by infra-red or ultra-sonic tech- 
niques. Transportable integrated circuit devices may be 
embodied in tokens of other than card shape. Regardless of 
sh^. such devices will be referred to herein as integrated 
circuit cards (ICCs). A difficulty with ICCs is that the writing 
of data to the ICC may be interfered with by disturbing the 
interface during writing whereby transients or failure in 
power, reset or clock signals may result in enoneous write. 

A smart card application to which the invention is par- 
ticulariy applicable is in a financial value or '^electronic 
cash" transfer system. Here, data in smart cards represents 
value which can be transferred on-line with banks and 
oflf-line between cards. Such a system is described in patent 
^pUcations Nos. W09iyi6691 and WO93/08545. It is 
clearly important In such q^lications to avoid the effects of 
erroneous data writing, either accidental or perhaps delib- 
erately instigated by manipulation of power or data lines. 
Hie present invention provides a solution. 

SUMMARY OF THE INVENTION 

According to the invention there is provided a method of 
writing data to non-volatile inem<Hy in an integrated circuit 
device, the device having an interface for ten4x>rary con* 
ncction to a terminal unit; a microprocesson random access 
memory and non*volatiie memory, the method consisting in 
allocating a first region of the non-volatile memory for data 
to be written, allocating a second region of non-volatile 
memory for write status information to be written, perform- 
ing a data write operation to write data to said first region, 
and writing information to said second region signifying a 
valid data write if. and only if, the data write operation is 
performed satisfactorily. 

In a microprocessor environment there are many copy and 
write procedures for transferring data and program informa- 
tion between regions of RAM and from RAM to EEPROM, 
for cxamjdc, and vice versa. At the operating system level or 
higher there are usually verification techniques available for 
verifying the validity of a copy or write (^>eration. This may 
involve an automatic comparison of the copied or written 
material with the original or. more usually, the provision of 
a checksum routine which adds one or more checksum hits 
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to the data which, in accordance with a particular algorithmu 
provide a link to the data which can be verified to ensure that 
no write or copy conq>utation has taken place. If corruption 
is detected the operation can be repeated until satisfactory. 
i The present invention is not concerned with such techniques 
and is additional to them, where provided. However, such 
inbuilt techniques can be used as the basis for determining 
whether the write operation has been performed satisfacto- 
rily in order to write the appropriate information into the 
10 second region of memory. Thus, for example, if data is 
successfully written to an ICC with inbuilt write verification 
techniques {nrscnt then the oondusion of the write process 
can be taken as indication of a satisfactory write to allow 
appropriate data to be written to the second region of 
15 memory. 

The type of non -volatile memory currently used in most 
smart cards is electrically erasable programmable read-only 
memory (EEPROM) and the invention is applicable 
particularly, but not exdusivdy to this. As far as reading and 
20 writing procedures are concerned EEPROM is generally 
divided into pages and reading or writing is carried out on 
one page only at a time. It can be expected that a transient 
writing otch' may corrupt the contents of one page but not 
others. Accordingly, it is prcfored that the first and second 
25 regions are on different pages. 

The invention allows the non-volatile memory to record 
wheAer there is an outstanding write error on the device and 
to take action accordingly when the device is used again, on 
application of a reset signal. Generally the protocol ISO 
30 7816 is used, which governs the nature of reset, answcr-to- 
reset power and clock signals etc. If the fault is transient, the 
reset signal may be applied immediately so diat an inter- 
rupted transaction may be resumed. If not. the reset signal is 
applied next time an attempt is made to use the device. 
35 Preferably, in accordance with an aspect of the invention 
there is provided a method of utilisation of an integrated 
circuit device to which data has been written as described 
above, the device induding in the non-volatile memory an 
application program whid) controls the microprocesscH- to 
40 run a particular ai^lication under normal circumstances, the 
utilisation nocthod including the step of initially reading the 
second portion of the non-volatile memory to derive write 
status information therefrom and, if the write status infor- 
mation indicates an incomplete write operation, by-passing 
45 said application {Hogram. 

Thus, die action effective when an outstanding write error 
is present on a smart card (for example) may be to render the 
card useless by continued failure to run the api^cation 
program. This is software invalidation of the card. 
so Alternatively, a hardware invalidation is possible by provid- 
ing an overload current to a fuse link in the card, thus 
blowing the fuse and rendering the card invalid. However, 
card invalidation is wasteful and preferably the method of 
utilisation indudes. on detection of an incomplete write 
55 operation, a procedure of data recovery effective to restore 
the device to a condition in which the last data write is 
correct and the status information in the second region of 
memory reflects this. Should the data recovery procedure 
fail, then the above-mentioned software or hardware steps of 
^ invalidating the card may be taken. 

As non-exhaustive cxanq)les of the way in which the 
invention may be used, three specific methods are proposed. 

METHOD 1 

63 In accordance with this method it is provided that respec- 
tive and separate regions of the non-volatile memory are 
allocated as: 
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(a) a sequence register which is said second region of 3. writing said new data to be written to said first region 
memory- non-vdatile memory; and 

(b) a data copy buffer; 4. dearing the state flag in register (k) 

V . Here, new data is typically wnttcn duccdy from RAM 

(c) a size register; and 3 and a copy is taken for the update copy buffer (n). If 

(d) an address register and aUocating a region of RAM or recovery is required, since it is the new daU which is held 
Don-volatflc memory as (c) a data incremental buffer. reserve in (n), the recovery procedure copies this to the 
the first region of non-volatile memory being identified required address in EEPROM (for cxanyjle). 

in size and address by data written in memory regions 

(c) and (d), the method of writing consisting in: jq BRIEF DESCRIPTION OF THE DRAWINGS 

1. ensuring that the buffer (e) contains a vaUd data ^^^^^^ ^ ^ ^.^ ^^^^^^ ^ 

2.5SSr?^pyof<latatobeupdatedinthebuff« the accompanying drawings, of whidi: 

3. iiKTemcnting the register (a); ™- 1 ^ scbemaUc diagr^ of a smart card having 

4. inaementing the date at the first region of memory . , EEPROM orgamsed to effed a first method of daU wntmg 
by the amount in buffer (e) and writing the incre- and recovery in accOTdance with the inveaUon; 

mental anwunl to the first region of memory; and FIGS. 2a-2B are a flow diagram in respect of ihe method 

5. incrementing the sequence register (a). used in the card of FIG. 1; 

Wth this method the recovery procedure, when the reg- piG. 3 is a schematic diagram similar to FIG. 1 but in 

ister (a) indicates recovery is necessary, consists in copying ^ respect of a second mctiiod of data writing and recovery in 

the original (unamended) data from buffer (b) to said first accordance with the invention; 

region of memoiy. This restores the situation to the position FIQS, 4A-4B arc a flow diagram in respect of the second 

before the faulty write operation. method; 

FIG. 5 is a schematic diagram similar to FIGS. 1 and 3 but 

Mii i riOD 2 25 uircspectof a tiiird method of data writing and recovery in 

In this method it is provided that respective and sqiarate accordance with the invention; and 

regions of ttic non-volatile memory are allocated as: FTGS. 6A-<iB are a flow diagram in respect of the third 

(0 a write in progress flag register, which is said second method, 

region of memory; ^ DETAILED DISCUSSION OF PREFERRED 

(g) a w(»kspace pointer register, EMBODIMENTS 

(h) a size register, and . , „ Referring to FIG. 1 there is shown a smart card I which 

(i) a data pointer rcgista: and allocating a region of RAM interface 2 comprising a set of contacts 3 for making 
or non-volatile memory as 0) a new data pointer comet with a luminal unit 4. In accordance with the 
register, the first region of non-volatfle memory bemg 35 protocol oflSO 7816 the terminal unit provides power, dock 
identified in size and position by daU written in signals, a reset signal and serial dato signals to the card. The 
memoiy regions (g) and (h), the method of wntmg card is an ICC device which includes a microprocessor 5, 
consisting in: I^y^ ^ and EEPROM 7. 

' worf^pace P^^^ '^^^^^ ^„w™^ ^ The EEPROM 7 is divided into a set of pages 8 and is 

(g) to the address of non-volatile im^mory workspace 40 1^ ^tfj^n operating system program OS, an appUcation 

suffidenttoholdaconuguousdausetcorrespondmg ^ ^P aJ^T(teU re^JoR whidi hSds data 

to a size set in registff (h); S may be read and rewritten. 

2. copying to the workspace a copy of new data wm«i m-jr . , ^ . . . 
ideitifi^ in address byTe new daU pointer at Q) "^T^f ^^T. 
and in size by the size data at (h); 45 METHOD 1, whidi is for in«mental updating of dau in 

3. setting the ^te in progress flag at (f); EEPROM. In acco^ce with this inctiiod ^ve and 

4. setting an address in dSa pointer register (i) to the separate regions of the data region DR of EEPROM are 
address of the work-^ce; and aUocatcd as: 

5. clearing the write in progress flag in register (f). (a) a sequence register; 
Here, the recovery procedure comprises repetition of the 50 (b) a data copy buffer; 

last two steps (4 and 5), since an error would indicate that (c) a size register, and 

the data pointer register had not been properly written. ^ address register. 

A regiwi <^ RAM is allocated as (e) a data incremental 

METHOD 3 h\iSa, altiiough this could alternatively be in EEPROM also. 
In this method it is provided that respective and separate ^5 Referring now to RG. 2(fl) there is shown a flow diagram 

regions of the non^volatile memory are aUocated as: for the writing of data in accordance with METHOD 1. The 
(k) a stotc flag register which is said second region of steps indude: 

memory; 1- ensuring that the buffer (c) contains a valid data 

(1) a size rcgisicr; 60 

o« -^^Icc «.»icr..r. anH 2. identifying the EEPROM daU to be updated (original 

rn) an address register and datarS^erence to the size and address registers (c), 

(n) an update copy buffer flie first region of non-volati^e ^ j^^^ 

memory bemg identified m size and posxuon by data ^ ^ . 7 . . *77 * . v « / ♦ 

written in rep^sters (1) and (m). the method of writing 3. copymg the ongmal data to buffer (b) (at 11) 

consisting in: 65 4. incrementing the sequence register (a) (at 12); 

1. copying new data to be written into buffer (n); 5. calculating the new data in RAM by reference to the 

2. setting the state fiat in register (k); cwiginal data and the data in the data increment buffer 
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(e) and write the new data back to the original location FIG. 7) to use a METHOD 2 in accordance with the 

in EEPROM (at 13); and invention. Here respective and scpamc regions of EEPROM 

6. incrementing the register (a) (at 14). (on respective pages 8) are allocated as: 

EEPROM is such that its stored data can be corrupted if, (f) a [□ progress flag register; 

whilst me content of the EEPROM is being c^gcdi, Ae 5 ^ workspace pointer register; 

power hne, or the clock signal arc intcmiptcd. With the T[ . J^.j-l __h 

arrangement described above, data security is provided by W a size register, ana 

the use of the data copy buffer in conjunction with the W a ™a pointw register, 

sequence register. By virtue of internal write verification ^ RAM there is allocated a region 0) as a new data 

procedures it can be assumed that if the opaating system pointer register. Alternatively this may also be in EEPROM. 

indicates completion of flie write procedure 13 then the A flow chart for the writing procedure in METHOD 2 is 

written information is in order and the sequence register (a) shown in FIG. 4(a). This includes the steps of: 

can be updated appropriately. If the write operation is 1. setting a workspace pointer in register (a) to the address 

interrupted by power line or dock signal disruption, for of a workspace in EEPROM sufSdent in size to hold a 

exan^le^ then the sequence register remains in its former contiguous data set corresponding to a size set in 

state whidi is not appropriate to the attempted write. ^ roister (h) (at 21); 

In accordance with an aspect of the invention there is a 2. copying to the workspace a copy of new daU in a region 

chedt and recovery procedure available ^n ttie card in RAM or EEPROM identified in size by register (h) 

receives the res^ signal at any tmie^ FIG^i.) Ulus^iaes 22); 

tfiis. On reset at 15 the sequence register is checked at 16 to ^ ^ ^ • m /!• '>^^. 

dctenmnewhetherawritefaUureisindicated.Ifnotthenthe 20 3. semng the wnte m progress flat (0 (at 23), 

^Ucation program AP(nG. 1) is executed at 17. If failure 4. setting the address in register (i) to the workspace 

is indicated then the original data before the last attempted address (at 24); and 

write operation, whidi is held in data copy buffer (b) is 5. clearing the write in progress flag in re fflstg - (f)- 

copied to the original data address (c), (d). This st^ is The check and recovery procedure for METHOD 2 is 

shown at 18. The situation before the attempted write 25 shown in FIG. 4(6). On reset at 25 the write in progress flag 

operation is thus restored. is checked at 26. If deared the application program AP is run 

This method is adapted to a multi-stage operation proce- at 27. If not then the last two steps (4 and 5) of the write 

dure and in practice data will be fed back and forth to the pax)ccdure are repeated. Thus, the data pointer (i) is set equal 

terminal by a serial interface in multiple stages. The to the WOTkspace pointer (g) at 28 and the write in progress 

sequence registci holds information as to the stage in the 30 flag (f) is deared at 29. If this write procedure succeeds 

sequence where Interruption takes place. If the original (check at 30) the program AP is executed. If not. then the 

interconnection to the terminal pertains and the operation smart card is unusable (at 31). 

sequence can be resumed then a re-synchronisation proce- If an area ci EEPROM is found where an EEreOM write 

dure takes place and at 19 there is a check to d^crmine cannot be completed, then this method readily aUows the 

whether copying/re-syndironisation has succeeded. If so 35 smart card application software to nwrk this area as unusable 

then the application program AP is run. If not the software (permanently), and choose another area for data storage, 

must dedde ftom the state of the sequence register how to This can greatly extend Ae life of toe smart card (which will 

re-synchronise the on-card application software and ttie very probably be limited by the maximum possible number 

software conununicating with the smart card via the serial of EEPROM writes that the smart card is capable of 

line. If data cannot be retrieved from the data copy buffer, 40 performing), however this is at the expense of maintainin g 

and the sequence register indicates that this data should be a pointer (a 2 byte oveihead) to each data structure stored in 

available, then the smart card is unusable, as indicated at 20. EEPROM. 

This may be by virtue of continued failure to implement Under normal conditiotts, the Write in Progress flag is 

the api^cation program or positive steps may be taken to only set fOT the time required to update a pointer in 

invalidate the card as, for exair^lc, by blowing an inbuilt 45 EEPROM. This is the minimum possible theoretical update 

fuse. time, which should hdp to ensure that the recovery mecha- 

The data copy buffer (b) and the data increment buffer (c) nism is invoked only very rardy. This minimises the number 

must both be large enough to hold the largest possible data of attempted writes to EEPROM, and thus extends the life 

block that will be written to EEPROM using this method. An of the smart card. 

extra 5 bytes of storage are also reqdred (size=2 bytes, 50 Each daU structure written to EEPROM using this 

address=2 bytes, sequence registert=l byte [at least]). If size method wiU be extended by two bytes, as a pointer to the 

can never be greater than 255, then it can be stored in a data must be continuously maintained. There is a small 

single byte. overhead on each EEPROM read as all data which uses this 

Since the card operates on only one page 8 (FIG. 1) at a method must be accessed via a pointer, 

time in writing, security is enhanced by ensuring that 35 The EEPROM pointed to by the Workspace Pointa must 

separate EEPROM pages (3 in total) are used for the data be large enough to hold the largest possible data structure 

copy buffer, the data increment buffer and for die rest of the that will be written to EEPROM using this method. This 

additional data. space is only required until the EEPROM write has been 

Using this method of writing to EEPROM. the number of successfully completed, at which point an equivalent length 

bytes actually written to EEPROM is doubled even if a 60 of EEPROM stwage (which used to contain the original 

recovery is not invoked (because a cq>y of the original data data) is rdeascd. An extra 7 bytes of staage are also 

must be stored in the data copy buffer before the EEPROM rcquh-ed (Write in Progress flag=l byte. New Data Pointer 

write commences). The total ovcrtiead is actuaUy slightly =2 bytes. Workspace Pointcp=2 bytes. Size =2 bytes). If Size 

more than this as size, address, and sequence register can never be greater than 255, then it can be stored in a 

information must also be written to EEPROM. 65 single byte. 

Referring now to FIG. 3 there is shown die EEPROM Using this method of writing to EEPROM, the data 

configuration for a smart card (otherwise similar to that of structure is only written to EEPROM once, but three point- 
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ers have to be updated (the New Data Pointer, the Workspace 
Pointer and the Data Pointer — in that order). The Size, 
Address and Sequence Regista information must also be 
written to EEPROM. 

Referring now to FIG. 5 there is shown EEPROM allo- 
cation for a METHOD 3 of implementing the invention. It 
is to be understood that the EEPROM of FIG. 5 is incor- 
porated in a smart card otherwise similar to that of FIG. 1. 
In FIG. 5. separate regions of EEE*ROM (on separate pages 
8) are allocated as: 

(k) a state flag register; 

(1) a size register, 

(m) an address register; and 

(n) an update copy buffer. 

The writing procedure in METHOD 3 is illustrated in 
FIG. 6(fl). The following steps are in^emented: 

1. Copy new daU into buffer (n) (at 32); 

2. Set state flag (k) (at 33); 

3. Copy the new data to EEPROM region identified by 
size (1) and address (m) (at 34); and 

4. Qear state flag (k) (at 3S). 

The check and recovery procedure illustrated in FIG. 6(b) 
has reset at 36, and a check for the setting of sUtc flag (k> 
at 37. If the flag is not set then application program AP is run 
at 38. Otherwise the new data residing in buffer (n) is copied 
to the region (1). (m) at 39 and the state flag (k) is cleared 
at 40. If successful, the af^lication program is run. If not, the 
card is useless (41). 

An additional Data area (buffer n) must be large enough 
to store the largest anxHint of data which will be written to 
EEPROM, plus 5 bytes (Size=2 bytes. Address=2 bytes. 
State Flag — 1 byte). If Size can never be greater than 255, 
then it can be stored in a single byte. 

Using this method of writing to EEPROM, the number of 
bytes actually written to ffiPROM is doubled even if a 
Recovery is not invoked (because a copy of the data must be 
written to EEPROM). The total overhead is actually slightly 
more than this as Size. Address must also be written to 
EEPROM. 

To be able to tell that data has not been altmd. error 
detection techniques must be implemented. Error detection 
usually comjffises calculating a checksum whenever the data 
is updated, storing this checksura and verifying that it is 
correct during every subsequent data read. The actual 
method used to calculate the error detection checksum is 
irrelevant for the purposes of this document, indeed some 
fimflrt cards have error detection {U'ocesses built into the 
EEPROM hardware, and their particular method of opera- 
tion may well not be known. 

An EEPROM write is deemed to be con^lete only when 
the error detection system has been approi»iatcly updated, 
and has been verified correctly. 
Each byte of EEPROM can only be changed a finite 
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corrected. This sim{difies the software and reduces the data 
stc^age requirements, as error correction is computationally 
intensive and requires more dedicated bytes of storage than 
error detection. 

One of the three methods of writing data to EEFROM 
described above (Method Number 1) explicitly keeps a 
counter (Sequence Register) which stares Imowledge of the 
last successful <^>eration in the series of operations per- 
formed during writing to EEPROM. Methods 2 and 3 may 
have, but do not cxpMdlly require a counter of this type as 
they r^ly upon flags v^cb hold information showing 
whelhff or not writing to EEPROM has successfully com- 
pleted. 

Even though a method of writing to EEPROM does not 
always explicitly require a numeric counter, it should be 
clearly noted that in many systems it will be necessary to 
maintain such a counter so that intcniiptcd processes of any 
kind can be restarted. It is of course vitally important for this 
counter to be written to EEPROM in a secure manner, as if 
it is not correct it cannot be relied upon by smart card 
application software atten4>ting to restart an interrupted 
process. 

We claim: 

1. A method of utilization of an integrated circuit device, 
the device having an interface for temporary connection to 
a terminal unit; a microprocessor; random access ix^mory 
(RAM) and non-volatile memory, the method of utilization 
including: 

a method of writing data to said non-volatile memory 
comprising: 

allocating a first region of the non-volatile niem<Hy for 
data to be written. 

allocating a second region of non-volatile memory for 
write status information, 

performing a data write operation to write data to said 
first region, and 

writing infonnation to said second region signifying a 
valid data write if. and only if, the data write opera- 
tion is performed completely, and 
the method utilization further including the method of 

responding to a reset of the device by the steps of: 

initially reading the said second region of the non- 
volatile memcHy to derive write status information 
therefrom and, 

if the write status infonnation indicates an incomplete 
write opaation, enabling invalidation of the inte- 
grated circuit device. 

2. A method of utilization of an integrated circuit device 
as claimed in daim 1 including the step of instituting 
recovery of data to the non-volatile memory, invalidation of 
the integrated circuit device being effected only on failure of 
said recovery. 

3. A method of utilization of an integrated circuit device 
as claimed in claim 1 wherein the non-volatile memory 
includes an a(q}lication program which controls the micro- 


number of times befoie it ceases to function correctly. This 55 processor to run a pOTticular ^lic^tion under normal dr- 
is typically iC to 10* write cycles. Therefore thereisa finite 
chance of daU being altered whilst it resides in EEPROM. 
and an EEPROM read must only be accepted as valid if the 
error detection system verifies that the data has not been 
altered. If an error is detected during an EEPROM read, it 
probably means that one or more bytes in the smart card's 
EEPROM have reached the end of their active life. 

Using one of the mefliods of writing to EEPROM 
described above ensures that error correction (as opposed to 
error drtection) is not required. Either the EEFROM opera- 
tion takes place successfully, or the smart card is unusable. 
TTiere are no circumstances in which an error needs to be 
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cumstances and invalidation of the integrated circuit device 
is software invalidation whereby said application program is 
by-passed. 

4. A method of utilization of an integrated circuit device 
as daimed in daim 1 wherdn invalidation of the integrated 
circuit device is effected by incapacitating the hardware of 
the device. 

5. A method of utilization of an integrated circuit device 
as claimed in claim 1 wherein the non-volatile memory is 
divided into pages and write operations are performed on 
only one page at a time, the first and second regions of 
memory being on different pages. 
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6. A method of utilization of an integrated circuit device 
as claimed in claim 1 wherein the non-volatile memory is 
electrically erasable programmable read-only memory 
(EEPROM). 

7. A method of utilization of an integrated circuit device 
as claimed in claim 1 wherein said second region of memory 
is a status register, said status information is indicative of the 
last satisfactorily performed stage of a multi-stage operation 
sequence and said data recovery jHOcedure is effective to 
recover the multi-stage operation sequence from the stage at 
which it failed, as indicated by the status register. 

8. A method of utilization of an integrated circuit device 
as claimed in daim 7 wherein respective and sepaiBtc 
regions of the non-volatile memory arc allocated as: 

a. a sequence register which is said second region of 
memory; 

b. a data copy buffer; 

c. a size register, and 

d. an address register and allocating a region of RAM or 
non-volatile memory as (e) a data incremental buffer, 
said first region of non-volatile memory being identi- 
fied in size and address by data written in memory 
regions (c) and (d). said method of writing comprising: 

1. ensuring that the buffer (e) contains a valid data 
increment; 

2. placing a copy of data to be updated in the buffer (b); 

3. incrementing the register (a); 

4. inaemcnting the data at the first region of memory 
by the amount in buffer ((e) and writing the incre- 
mental amount to the first region of memory; and 

5. incrementing the sequence register (a). 

9. A method of utilization of an integrated circuit device 
as claimed in claim 8 wherein the recovery procedure 
includes copying the data from the data buffer (b) to said first 
region of memory. 

10. A method of utilization of an integrated circuit device 
as claimed in claim 1 wherein said second region of mcmsxy 
IS a flag region and said status information is a flag which is 
set if said write operation is verified as satisfactory and 
which is otherwise not set. 

11. A method of utilization of an integrated circuit device 
as claimed in claim 10 wherein respective and separate 
regions of the non-volatile memory are allocated as: 

f. a write in progress flag register, which is said second 
region of memory; 

g. a workspace pointer register; 

h. a size register, and 

1. a data pointer register and allocating a region of RAM 
or non-volatile memory as (i) a new data pointer 
register, said first region of non-volatile memory being 
identified in size and position by data written in 
memory regions (g) and (h). said method ci writing 
comprising: 

1. setting a workspace pointer in register (g) to the 
address of non- volatile memory workspace sufBcient 
to hold a contiguous data set corresponding to a size 
set in register (h); 


5,431 

10 

2. copying to the workspace a copy of new data 
identified in address by the new data pointer at (j) 
and in size by the size data at (h); 

3. setting the write in progress flag at (f); 

5 4. setting an address in data pointer register (i) to die 
address of the workspace; and 
5. clearing the write in progress flag in register (f). 

12. A method of utilization of an integrated circuit device 
as claimed in claim 11 wherein the recovery procedure 

iQ comisises the sxeps of setting the address in data pointer 
register (i) to the address of the workspace and clearing the 
write in progress flag in register (f). 

13. A method of utilization of an integrated circuit device 
as claimed in claim 10 wherein respective and sq>arate 

15 regions of the non-volatile memory are allocated as: 

k. a state flag register which is said second region of 

memory; 
1. a size register, 
m. an address register, and 
20 0. an iq>date copy buffer said first region of non-volatile 
memory being identified in size and position by data 
written in registers (1) and (ra). said method of writing 
coirpising: 

1. copying new data to be written into buffer (n); 
25 2. setting the state flag in register (k); 

3. writing said new data to be written to said first region 
(rf non-volatile memory; and 

4. clearing the state flag in register (k), 

14. A method of utilization of an integrated circuit device 
^ as claimed in claim 13 wherein the recovery procedure 

comprises the steps of copying the contents of the update 
copy buffer (n) to said first region of non-volatile memory 
identified by die contents of the registers Q) and (m) and 
clearing the flag in register (k). 
55 IS. An integrated circuit card (ICC) device comprising: 
an interface for temporary connection to a terminal unit; 
a micToprocessOT responsive to said interface; 
a random access memory (RAM) connected to said 

microprocesscB'; and 
a non-volatile memory connected to said micrc^ocessos'. 
said non-volatile memory furtiier including: 
a first region for storing data to t>e written, 
a second region for staring write status information, 
said microprocessor including programming: 
for performing a data write operation to write data to 

said first region; 
for performing a data write operation to said second 
region signifying a valid data write status if. and 
only if. the data write operation to said first region 
is performed con^lclely; 
for reading, in response to a reset of the device, said 
second region of the non-volatQe memory to 
derive write status information therefrom; and 
enabling, if the write status infomation indicates an 
inconq)lete write operation, invalidation of the 
integrated circuit device. 

4i * * * * 
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(57) ABSTRACT 

A method and apparatus annotates a computer program to 
facilitate subsequent processing of the program. Code rep- 
resenting the program is generated at a first computer 
system. Annotations are generated for the code that provide 
information about the code. At a second computer, the code 
is processed according to the information provided by the 
annotations. The annotations, for example, can indicate a 
control flow graph representing a flow of execution of the 
code. Also, the information provided by the annotations can 
be a register allocation that maps data structures of the code 
to registers of the second computer system. The second 
computer system can use such information to guide the 
interpreting of the code or to transform the code into a more 
optimized form. Other exemplary annotations can indicate 
that running the executable form of the code would perform 
an unauthorized operation at the second computer system. 
The second computer systcni could then reject the code 
instead of performing subsequent processing on the code. 
When the source of the annotations is un trusted by the 
second computer system, the second computer system can 
use a checker to verify the integrity of the annotations. 
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METHOD AND APPARATUS FOR 
ANNOTATING A COMPUTER PROGRAM TO 
FACILITATE SUBSEQUENT PROCESSING 
OF THE PROGRAM 

5 

HELD OF THE INVENTION 

This invention relates generally to the processing of 
mobile, computer programs, and more particularly to anno- 
tating such programs to assist downstream processing 
phases. 

BACKGROUND 

In computer systems, and particularly in networked com- 
puter systems, computers commonly acquire programs to 35 
execute from other computers. Before executing an acquired 
program, the acquiring computer typically performs pro- 
cessing on the program. For example, the computer may 
compile the program into machine language native to that 
computer. As another example, the computer may verify that 20 
the program satisfies certain security constraints. This veri- 
fication is particularly important because, generally, the 
computer distrusts the acquired program; the security checks 
ensure that the program does not tamper with files and other 
resources of the computer. 25 

FIG. 1 illustrates a typical prior art network 100 in which 
a first computer 110 uses a program processing tool 112 to 
verify and compile a program downloaded from a second 
computer 120. The program downloaded from the second 
computer 120 is in an intermediate fonm 130 that represents 30 
the program. The second computer 120 tjsed an intermediate 
code generator 150 to generate the intermediate form 130 
from source code 140 of the program. At the first computer 
110, the processing tool 112 analyzes the code 130 to 
determine whether the code 130 is safe to compile and 35 
execute. The tool 112 also performs code optimization 
techniques to produce executable machine code 160 native 
to the first computer 110. 

Security checks and compiler analyses consume system 
time and, as a result, can reduce performance. These analy- 
ses can also be ineffective because of insufficient informa- 
tion to perform a proper security check or insufficient time 
to thoroughly process available information. 

Security checks, for example, may err on the side of 
caution and reject secure code because the information 
necessary to prove that the code is secure is lacking. 
Moreover, a security check itself may be a source of 
vulnerability because it is incorrectly designed or improp- 
eriy implemented. Unwittingly, this security check may 
leave open doors for attack. Also, some compilers, such as 
just-in-time compilers, may not have sufficient time to 
perform thorough analysis for optimization. Without enough 
time for optimization, the machine code may perform 
poorly. 

As a result, a need remains for a method and an apparatus 
that facilitate security checks and code analyses. Such a 
method and apparatus can lead to improved accuracy of the 
security checks and to machine code that performs better 
than what can currently be generated. 

SUMMARY 

In accordance with the present invention, an objective is 
to enhance program code, such as mobile code, with supple- 
mentary information that will help subsequent processing 65 
stages. Having such information available during subse- 
quent processing stages will, for example, lead to more 
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accurate determinations of the security of the code and to 
improved performances of generated machine code. 

A method performed according to the principles of the 
invention achieves the aforementioned and other objectives 
when processing intermediate code generated at a first 
computer system by generating annotations for the code. 
The annotations provide information about the intermediate 
code that can be used to process the code. A second 
computer system receiving the code and the annotations can 
then process the code according to the information provided 
by the annotations. 

^rhe annotations, in genera], provide information that is 
useful to the second computer system for processing the 
code. For example, the annotations can be a control flow 
graph that represents an execution flow of the code. Also, the 
annotations can provide a register allocation that maps the 
data structures of the code to machine registers of the second 
computer system. Other annotations can provide method 
ofikets. Such information provided by the annotations can be 
useful to the second computer system, for example, when 
interpreting or compiling the code. As yet another example, 
the annotations can indicate whether running the code would 
perform unauthorized operations on the second computer 
system. 

These annotations can be generated at a number of 
locations in a network before being transmitted to the second 
computer system. For example, the first computer system 
that produced the code can also produce the annotations and 
send both the code and the annotations to the receiving 
computer system. The first computer system may produce 
the code and the annotations concurrently or produce the 
annotations after the code has been generated. Also, the first 
computer system may add the annotations to the code and 
send both together to the second computer system, or store 
the annotations separately from the code and transmit the 
annotations and code separately. In still another example, a 
third computer system between the first and second com- 
puter systems, for example, a computer on a firewall pro- 
tecting the second computer system from receiving poten- 
tially harmful programs, can generate and transmit the 
annotations to the second computer system. 

Just as code from the first computer cannot always be 
trusted, downloaded annotations should also not be trusted 
unless a trusted system, such as the aforementioned third 
computer system on the firewall, generated the annotations. 
When the annotations come from an untrusted system, the 
second computer system must check the correctness of the 
annotations that the second computer system uses. Checking 
the analysis provided by the annotations, however, is often 
faster and simpler than performing the analysis, so the 
invention still improves the performance and reduces the 
vulnerability of the second computer system. 

In terms of the disclosed apparatus, the invention com- 
prises a first computer system and a second computer system 
coupled to each other by a network. The second computer 
system requests a computer program from the first computer 
system. An annotator generates an annotation for the pro- 
gram. The annotation provides information about the pro- 
gram that characterizes the program. The second computer 
system receives the code and the annotation and processes 
the code according to the information provided by the 
annotation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram schematic of an embodiment of 
the present invention; 
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FIG. 2 is another more detailed block diagram schematic 
of an embodiment of the present invention; and 

FIG. 3 is a block diagram of an exemplary application of 
the present invention 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMEN T 

FIG. 2 shows an exemplary networked computer system 
200 including a program annotator 220 coupled to a first 
computer 210 and a second computer 230. For purposes of 
illustration, the user of the second computer 230 does not 
trust the first computer 210 or any code coming from the first 
computer 210. lliis means that the user of the second 
computer 230 does not know whether an executable form of 
the code 212 will perform any unauthorized operations, such 
as accessing files and directories of the second computer 
230. Accordingly, the user of the code 212 should verify the 
integrity of untrusted code before executing it. The first 
computer 210 includes an intermediate code generator 214 
that converts source code 216 of a computer program into an 
intermediate code 212. The source code 216 can be written 
in any programming language, such as Java, C or C*, but 
the intermediate code generator 214 must be able to process 
the semantics and syntax of that programming language in 
order to produce the intermediate code 212. The intermedi- 
ate code 212 produced by the generator 214 is machine- 
independent, that is, the code 212 itself does not run on any 
particular computer without further processing, e.g., inter- 
preting or compiling. It is to be understood that the practice 
of the principles of the invention is not limited to interme- 
diate code, but rather that annotations can be generated for 
various other types of code, such as, for example, source 
code, machine code, machine-dependent or machine- 
independent code, high-level or low-level code, assembly 
code, etc. 

The annotator 220 includes an intermediate code analyzer 
222 that analyzes the intermediate code 212 from the first 
computer 210 and produces annotations 224 as a result. This 
analysis can include, for example, mapping variables to 
registers, determining a control flow of the code 212, 
determining methods for optimizing the code 212, checking 
that all data structures are initialized and that the code 212 
is syntactically well-formed, contains valid references to 
data structures, data fields, and other code, and verifying that 
operations performed by the code 212 do not underflow or 
overflow the stack. ITiese examples are simply illustrative. 

From the annotator 220, the intermediate code 212 and the 
annotations 224 pass to the second computer 230. Although 
shown in FIG. 1 to be separately forwarded to the second 
computer 230, the intermediate code analyzer 222 can 
annotate the code 212 so that the annotations 224 are placed 
in the code 212, producing an annotated intermediate code. 
As a result, the code 212 and the annotations 224 arrive 
concurrently at the second computer 230. 

Placing the annotations 224 in the code 212 displaces the 
need for locally caching the analysis. Before the present 
invention, each user of the intermediate code 212 would 
store the analysis performed on the code 212 for subsequent 
use. lliis way, the computer would not have to repeat the 
analysis each time the intermediate code 212 was down- 
loaded. With local caching, however, only the computer with 
the cached analysis benefited from that analysis. Using the 
present invention, the analysis that is recorded by the 
annotations 224 in the intermediate code 212 can benefit any 
user whh access to the annotated intermediate code. 

llie annotator 220 can reside at the first computer 210 or 
at a third computer (not shown) connected to both the first 
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and second computers 210, 230. Conceivably, the annotator 
220 could reside at the second computer 230, but the benefits 
of annotating are greater when the intermediate code 212 
arrives at the second computer 230 already annotated. 

Normally, it would be easier to annotate the intermediate 
code 212 at the same computer where the intermediate code 
212 is produced because of the availability of the original 
source code 216. For example, when the annotator 224 
resides at the first computer system 210, the code and the 
annotations 224 can be produced concurrently, or the anno- 
tations 224 can be produced after the code has been gener- 
ated. Having the annotator 220 reside at the first computer 
210, therefore, produces advantages. On the other hand, the 
annotations 224 produced by the first computer 210 are 
untnisted because the first computer 210 is untrusted. Thus, 
the second computer 230 should verify the integrity of the 
annotations 224. 

For this purpose, the second computer 230 has a checker 
240 for verifying the integrity of the annotations 224. 
Because it is often faster and simpler to check annotations 
than to produce annotations, the advantages of annotating at 
an untrusted system remain. The checker 240 can immedi- 
ately reject the code 212 when the checker 240 determines 
that the annotations 224 are invalid. Invalid annotations 224 
include those annotations that present a false representation 
of the operation of the code 212 or perform operations that 
are unauthorized by the second computer 230 or are not 
well-formed, i.e., fail to follow a particular format. 
Conversely, vahd annotations 224 are we 11- formed and 
accurately reflect the operation of the code 212. The checker 
240, then, can quickly conclude from the annotations 224 
whether the intermediate code 212 should be subsequently 
processed, e.g., interpreted or compiled. 

The dashed lines in FIG. 2 indicate that the second 
computer 230 may not need a checker 240 when the anno- 
tations 224 come from a trusted source. An example of a 
trusted source is a third computer (not shown) at a firewall 
between the first computer 210 and the second computer 
230, protecting the second computer 230 from harmful 
programs. The annotator 220 can reside at this third com- 
puter and produce annotations 224 that are trusted by the 
second computer 230. 

The second computer 230 includes a compiler 234 for 
transforming the intermediate code 212 into executable 
machine code 250. The machine code 250 is dependent on 
the microprocessor running the second computer 230. The 
compiler 234 has added capabilities for handling the format 
of the annotations 224 and for using the annotations 224 as 
guidance during construction of the machine code 250. For 
example, the additional capabilities of the compiler 234 
include analyzing the annotations 224 and rejecting the 
intermediate code 212 when the annotations 224 indicate 
that the code 212 is not secure. The compiler 234 can also 
reference the annotations 224 to optimize the machine code 
250. Alternatively, the second computer 230 can include an 
interpreter capable of using the annotations to determine 
whether to execute the intermediate code 212 and then for 
guidance during any subsequent code execution. 

ANNOTATIONS 

In general, the annotations 224 produced by the analyzer 
222 include any information about the code 212 that can be 
obtained from static analysis. This information facilitates 
subsequent processing of the code 212. llie annotations 224 
that provide information about the code 212 are various and 
fall into at least two types: annotations that characterize 
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properties of the code; and aanotations that are in the form 
of a formal proof of the code. This categorizing of annota- 
tions is not intended to be exhaustive, but rather to distin- 
guish annotations that characterize properties of the code 
from annotations that arc a proof of the code. 

The first type of annotations 224, those that characterize 
properties of the code 212, provide the second computer 230 
with information that assists in a wide variety of subsequent 
processing of that code 212. Such subsequent processing 


code 250 through efiScient use of the machine registers. This 
register allocation can benefit just-in-time compilers that 
commonly make sub-optimal use of the registers because of 
the limited time in which to analyze intermediate code 212. 

Still other annotations 224 that characterize the code 212 
can provide method offsets. Method offsets direct the com- 
piler 234 to locations within an object where the compiler 
234 can find particular methods. These annotations can help 
the compiler 234 avoid clashes in method offsets in situa- 


includes determining whether the code is safe for additional lo tions of multiple inheritance. Still others 224 may show 

subsequent processing, such as executing machine code, or when a level of indirection can be removed from a data 

interpreting or compiling intermediate code. For example, structure. 

when the code 212 is in machine code form, this type of Annotations of the second type provide a formal proof of 
annotations 224 contains information about how the code some property of the code. The formal proof uses formal 
accesses memory, allowing the second computer 230 to ^5 logic reasoning about the code. The proof assures that the 
conclude that this machine code is safe to execute, or such code wUl behave according to a prescribed policy when that 
annotations 224 can contain information about what regis- proof is validated. An example of the second type of 
ters are live at different program points, allowing the code to annotations is described by George Nccula in "Proof- 
be optimized for increased performance. Alternatively, when Carrying Code". 1997, incorporated by reference herein, 
the code 212 is in an intermediate code form, the annotations 20 There, a compiler adds a formal proof to native binary code 


can provide useful information for optimally interpreting the 
intermediate code or transforming the intermediate code into 
an executable form. 

The information provided by these annotations can range 
from a detailed description of a particular property of the 
code to a broad, overall perspective of the entire code 212. 
For instance, exemplary annotations can characterize the 
behavior of a single code statement, a block of code 
statements, or the flow of execution of the entire code 212 


while the compiler produces the binary code. When the 
proof is validated, the binary code is deemed safe to execute. 

Annotations of the second type can be used to practice the 
principles of the present invention. A proof provided by such 
25 annotations can be used to determine whether code should 
be subsequently executed, i.e., compiled or interpreted. 
When the proof Ls validated, annotations of the previously- 
mentioned first type can then be used to guide such subse- 
quent execution. In general, to produce annotations, the 


The following examples are Uluslrative of Ihe diversity and '° f.f^'y^^' ^22 statically analyzes the intermediate code 212 


35 


like a conventional compiler. Off-loading the analyses to the 
analyzer 222 allows the second computer 230 to more 
quickly and more effectively process the intermediate code 
(e.g., produce better machine code 250) than if the second 
computer 230 had to perform its own analyses. This is 
because the annotator 220 may have more time than the 
second computer 230 to produce a more thorough analysis. 
Also, the annotator 220 may have access to available source 
code 216, whereas such information may not be available to 
40 the second computer 230. 

FIG. 3 illustrates an exemplary application using the 
principles of the present invention to process a computer 
program. A communication network 300 connects a server 
302 in the network 300 with a client computer 304 by 
network link 306. An example of such a network 300 is the 
Internet. The server 302 supports a web page; that is, the 
server 302 maintains documents, pages and other forms of 
data for retrieval. Applets, which are small programs com- 
piled to an intermediate form, might be attached to the web 


uses of annotations that characterize properties of the code. 
Any one or all of these exemplary annotations may be 
generated for the code 212 and used by the second computer 
230 as aid in the subsequent processing of the code 212. 

Exemplary annotations 224 of the first type can indicate 
what variables are used in the code 212 and the types of 
values stored in those variables. The particular annotation 
for the code statement 

"Xi:=0", 

for example, can be 

{Xji integer, Xj: undefined}, 

where and X2 are the two variables used by the inter- 
mediate code 212. This particular exemplary annotation 
indicates that at this point in the code 212, the variable 
holds a data structure of an integer type, while the type of the 
data structure in Xj is undefined. Such annotations 224, for 

example, can simplify and accelerate for the second com- 50 page when the web page is retrieved, 
puter 230 the task of type-checking data structures of the The server 302 includes an annotator 303 that statically 
code 212 to determine whether the intermediate code 212 is analyzes and annotates, according to the principles of the 
secure for subsequent execution. Thus, the .second computer invention, each applet attached to the web page. That the 
230 can determine beforehand that run-lime checks of the annotator 303 statically analyzes the applet before the applet 
intermediate code 212 are unnecessary. As another exem- 55 is sent to the client 304 distinguishes the present invention 


45 


plary use of such annotations, the information about the data 
types can assist run-time optimization by enabling tag-less 
garbage collection. 

Another exemplary annotation 224 is a control flow graph 
that represents the flow of execution of the entire code 212. 
Some exemplary annotations 224 can be less encompassing 
and represent the behavior of blocks of code statements. 
Such annotations 224 for blocks of statements can be placed 
at a block entry point, at an exit point, or at both points. 

Other annotations 224 can map data structures to machine 65 
registers of the second computer 230. The mapping of data 
structures to machine registers can help optimize machine 


from known techniques, such as a Java'^'^ virtual machine, 
that analyze the applet at the client 304. 

The client 304 includes memory 310 for storing a browser 
312, an annotation checker 314, and a compiler 316, The 
60 memory 310 can include a hard disk and main memory. The 
browser 312 provides a user of the client 306 with an 
interface that simplifies access to the server 302. Examples 
of a browser are Netscape Communicator**"" and Microsoft 
Internet Explorers'^". 

During an execution of the browser 312, the client 304 
can request access to the web page on the server 302. Tha 
browser 312 issues the request to the server by the link 306. 
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In response to the request, the server 302 returns the data 
associated with the requested web page to the client 304. 
When the retrieved web page is accompanied by an attached 
applet, the server 302 sends the annotated intermediate code 
representing the applet to the client 304. 

When the server 302 is trusted by the client 304, the client 
304 can process the annotated intermediate code according 
to the annotations embedded in the code without having to 
verify the annotations. This processing can include checking 
the safety of the applet and executing the applet. As used in 
this context, "executing" means interpreting or compiling. 
For example, the annotations may provide typing of the 
variables in the code from which the browser can determine 
whether the applet is safe to execute on the client 304. As 
another example, the annotations can suggest register 
allocations, for example, that help the browser execute the 
applet through efiBcient use of machine registers of the client 
304. 

Typically, however, the client 304 does not trust the applet 
produced by the server 302. In this event, the client 304 
would analyze the annotations along with the applet to make 
sure that the applet would not perform any unwanted opera- 
tions when the applet runs on the client 304. The checker 
314 accordingly verifies the integrity of the annotations in 
the applet code. The browser 312 rejects the applet when the 
checker 314 determines that the annotations are false. On the 
other hand, when the checker 314 determines that the 
annotations are valid, the browser 312 can process the 
applet, as previously noted, according to the annotations in 
the applet code. 

Although described within the context of the Internet and 
web browsers, the invention can be practiced within any 
other context where programs are annotated to facilitate 
subsequent program processing stages, llie foregoing 
description has been directed to specific embodiments of this 
invention. It will be apparent, however, that variations and 
modifications may be made to the described embodiments, 
with the attainment of all or some of the advantages. It is the 
object of the appended claims, therefore, to cover all such 
variations and modifications as come within the spirit and 
scope of the invention. 

What is claimed is: 

1. A computerized method for processing code represent- 
ing a computer program, the code being generated at a first 
computer system, the method comprising the steps of: 

generating an annotation for the code that characterizes at 
least one property of the code; 

analyzing the annotation, at a second computer system, to 
determine whether the code can safely operate at the 
second computer system and to provide information for 
optimizing the code's operating performance; and 

transforming and optimizing the code into an executable 
code in the second computer according to the informa- 
tion contained in the annotation if the analysis indicates 
that the a)de can be safely operated. 

2. The method of claim 1 further comprises interpreting 
the code according to the information provided by the 
annotation. 

3. The method of claim 1 wherein the annotation includes 
information on register allocation that maps data structures 
of the code to registers of the second computer system. 

4. The method of claim 1 wherein the annotation includes 
information on a control flow graph representing a flow of 
execution of the code. 

5. The method of claim 1 wherein the annotation includes 
information on a method oflset. 

6. llie method of claim 1 wherein the annotation indicates 
data types of variables in the code. 
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7. The method of claim 1, further comprising the step of: 
verifying at the second computer system that the annota- 
tion is valid. 

8. The method of claim 1 wherein the generating of the 
annotation occurs at the first computer system. 

9. The method of claim 1 wherein the generating of the 
annotation occurs at a third computer system. 

10. The method of claim 1, further comprising the step of: 
adding the annotation to the code to produce annotated 

code; and 

sending the annotated code to the second computer sys- 
tem. 

11. The method of claim 1 wherein the code Ls interme- 
diate code requiring processing before the code can operate 
at the second computer system. 

12. The method of claim 1, further comprising the steps 
of determining from the information provided by the anno- 
tations whether the code can be trusted to operate at the 
second computer system and operating the code only if the 
code can be trusted. 

13. The method of claim 1 wherein the code is trusted to 
operate at the second computer system when the annotations 
are generated at a trusted computer system. 

14. The method of claim 1 wherein determining whether 
the code should be processed includes determining whether 
running an executable form of the code would perform an 
unauthorized operation at the second computer system. 

15. An apparatus for processing a computer program, 
comprising: 

a first computer system and a second computer system 
coupled to each other by a network, the second com- 
puter system requesting a computer program from the 
first computer system; 

an annotator, coupled to receive the program, generating 
an annotation for the program, the annotation charac- 
terizing at least e property of the program; and 

the second computer receiving the code and the 
annotation, the second computer analyzing the annota- 
tion to determine whether the code can safely operate 
at the second computer system and provide information 
for optimizing the codecs operating performance, and if 
the analysis indicates that the code can be safely 
operated, the second computer system transforming 
and optimizing the code into an executable code in the 
second computer according to the information con- 
tained in the annotation. 

16. A system for processing a computer program, the 
system comprising: 

a first computer system and a second computer system 
coupled to each other by a network, the first computer 
system comprising a means for generating code; 

means for generating an annotation for the code, the 
annotation providing information that characterizes at 
least one property of the code; 

means for analyzing the annotation, at the second com- 
puter system, to determine whether the code can safely 
operate at the second computer system and to provide 
information for optimizing the code's operating per- 
formance; and 

means for transforming and optimizing the code into an 
executable code in the second computer according to 
the information contained in the annotation if the 
analysis indicates that the code can be safely operated. 
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ABSTRACT 


According to a portable electronic apparatus process- 
ing system of this invention, when an IC card receives 
instruction data, it checks if a function code can t>e 
completely input. If the function code is not completely 
input, the IC card sets data **I^' (hexadecimal code) as 
the function code, and outputs it to an IC card reader/- 
wrilcr. When the IC card reader/writer outputs an 
instruction to the IC card, it appends sequential number 
data to the instruction. The IC card executes processing 
corresponding to the supplied instruction. When the IC 
card outputs the processed result to the IC card rea- 
der/writer, it appends the sequential number data from 
the IC card reader/writer to the processed result and 
outputs it. 
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PROCESSING SYSTEM WHICH TBANCiurrc * *° portable electronic apparatus handlins apparatus 

nUNa^IONfSS^ < ' processing corresponding to the received in- 

IKANSMISSION CODE s Struction. and output a processed result with the lunc- 

This is a continuation of apolication Ser No '° electronic 

07/36139.rdedonJun.5:i9/9.:?£"wla£ldoSl S 

upon the fUing hereof which is a continuation of Ser. oh^lj«„ > r « u , • ..... 

No. 07A)97,660 filed Sep. 16. 1987, now abandoned 10 ^^IZ^ ^^^T^Tl!^ the function code of 

lu the instnicuon supphed from the portable dec- 

BACKGROUND OF THE INVENTION tronic ^paratus handling apparatus is input; and 

The present invention relates to a processing system outputting, to the portable clec- 

for a portable electronic apparatus, e g an IC c^d ^«>nic apparatus handhng apparatus, spcscific data 

Recently, an IC card incon>orating an'lC chip having 13 ««lK»tmg that the ftmctioD code is not input when 

a nonvolatile data memory and a control clement such checkmg means determines that the function 

as a CPU (Central Processing Unit) has been developed. ^ ''"^ ^^"^ 

An IC card of this type is normally operated usinga t T^.™^ ^ ^ present mvcntion, when IC card 1 

card reader/writer. This operation is performed by an J^'^ instruction data, it checks if a function code can 

instniction supplied from the card reader/writer The 20 ^ "^P^^V "^v"*- If is not completely received, 

IC card decodes an operation code (OP code) of the ' in an OP code portion of 

received instruction, and executes a series of processing «Sf»ns« data to be output to card reader/writer 2. As a 

corresponding to a function indicated by the OP code. wrong data cannot be output as an OP code. 

Then, the IC card outputs the processed result to the ^^^^ the conventional system. Therefore, even 

card reader/writer as response data. In this case, a func- 25 ^^.^ instruction dau is sent from card rcader/- 

tion code included in the input instruction is attached to ^^f^ ^ instruction cannot be normally 

the response data to compensate for the irregular se- received due to transmission noise, sequence disorder 

quence of instructions exchanged between the IC card '>ctween card reader/writer 2 and IC card 1 can be 

and the card reader/writer. More specifically, the OP diniinated. 

code is extracted from the instruction stored in a buffer 30 ^ sequential number starting from a specific initial 

upon an input of the instruction data, and the extracted ^^"^ ^ attached to instruction data output from the 

OP code is attached to the processed result when the reader/writer. The IC card receiving the instruc- 

processed result is output to the card reader/writer. attaches the sequential number of the received 

However, with this method, when no OP code is instruction to response dau and outputs it so that se- 
included in the instruction from the card reader/writer 35 qnencc disorder that cannot be prevented by response 

(m the case of an Ulegal instruction), or when the in- data with only a function code can be prevented. More 

siructiOT cannot be normally received due to transmis- specifically, since the sequential number attached to the 

sion noise, wrong data may be output to the card rea- instruction data is attached to the response data, the 

der/wnter as the OP code. This is because a portion relationship between the instruction and the response 
correspondmg to the OP code of the instruction stored 40 data can be easily discriminated from the sequential 

m the buffer is simply extracted and atuched to the number. In particular, when instructions having the 

processed result as the OP code. For this reason, when same OP code are successively transmitted a plurality 

a sequence between the card reader/writer and the IC of times, sequence disorder between the card reader/- 

card IS disordered, the compensation may be impossible. writer and the IC card can be reliably prevented 
In particular, when instructions having the same OP 45 r^^^^^ _ 

code are successively transmitted a plurality of times, ^^^^^ DESCRIPTION OF THE DRAWINGS 
Uie sequence may often be disordered. When sequenc^ RG. 1 is a block diagram showing the arrangement 
flisorder occurs upon transmission of data write instruc- of a conventional card handling apparatus- 
toon data, an abnormality such as double writing of daU HG. 2 is a block diagram showing fiictions of a 

50 conventional IC card; 

SUMMARY OF THE INVENTION /^^. J ^^^^ diagram showing the arrangement 

..... ^ of an IC chip mcorporated in an IC card to which the 

It IS an object of the present invention to provide a present invention b applied- 

pwwsmg system for a portable electronic apparatus FIG. 4 is a block diagraiA showing the arrangement 
which can ehminate sequence disorder between a card 55 of a conventional cardrcadcr/writer 

Mder/wnterand an IC card when an illegal instruc- FIG. 5 is a flow chart for explaining the operation of 

tion IS sent from the card reader/writer or when an a conventional card reader/writer- °P^o° 

mstniction cannot be normally received due to trans. FIGS. 6A and m show formals of a conventiomU 

mission noise, and which can reliably prevent sequence instruction output from a card reader/^»^te^ 
disorder between the card reader/writer and the IC 60 RG. 7 is a fiow chart for explaining the oSer^ion of 

card when mslrucuons havmg the same OP code are a conventional IC card- operwion or 

successively transmitted a plurality of times. FIG. 8 shows a formkt of response daU cutout from 

In order to achieve the above object, according to the an IC card- response daU output from 

Slut^tv ^ ^^''^'''^'^ processing system HG. 9 is a fiow chart for explaining instruction fetch- 

constituted by a portable electronic apparatus handDng 65 ing and processing operations of the IC cardZ^r^L 

S^^^^r , . ^ '^"'""^ °^ processing, HG. 10 shows a format of an instru^i^^n output from 

and a portable electromc apparatus which is connected a card reader/writer; 
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FIGS. nA«.dllBshol formats of -ninsmiction era«We progfanunable «ad^nly memory (EE- 
output from the card reader/wnter; r«H reader/writer 2 exchanges an OP code or data 

the ICcSdta Ac embodiment ofthe present invention; mechanism 21 for conveymg IC card » * 

aata memory 25 for stormg data. . , ^ 

DETAILED DESCRIPTION OF THE HG 5 is a flow chart showing the operation of card 

PREFERRED EMBODIMENTS „ ^^r^^ter 2. More specilkaJly. it is checked in ste^ 

FIG. 1 shows the arrangement of a card handling 31 if an instruction is suppUed ^PU 3. U NO m 
.pparatus used as a terminal for a home bankmg system ^ep 31. the flow returns to rtep M. "^.9^" ^'^''f 
^^TS^ing system to which an IC card as a portable i„p„t data. If YES in step 31. it is checked in «*PM J 
S^tSSSteVPlied-Thecardhandlingappa- ,c^eard 1 is in operation. If YES « step »• «»P°»^ 
Sm^JSTcard rSler/writer 2 for performing M indicting a multi instniction error is output to 
read/write access of the IC card 1, keyboard 4 form- cPU 3. and the flow returns to step 31. 
nutting dau such as a personal identification number ,f no in step 33. control advance to «ep 37. w>d an 
(PIN) CRT display unit 5 for displaying transaction ins,roction is output to IC card I. In step W, t-ru m 
dau. printer 6 for printing out the transaction data. ,^^43 jata from IC card I. If the response 

floppy disk 7 for storing the transaction data, and cen- 25 detected in step 39, control •dvances to step 41. 

tral processing unit (CPU) 3 for controlling card rea- ^ ^ ^ response data te output to CPU 3. 
der/writer 2. keyboard 4, CRT display unit 5, printer 6, pjQg instrucUon formats output to 

and floppy disk 7. . ic card 1. FIG. 6A shows an instructionformatconsist- 

IC card 1 is carried by a user, subjected to collation ^ qP code 77, and FIG. 68 shows an in- 

with a PIN known only by a user upon purchasing of 30 ^^^^^^ formal consisting of an OP code 77 and data 
commodities, and used to store necessary data. .79. . . .. « 

FIG 2 shows functional blocks of IC card 1. IC card ic card 1 is operated in accordance with the flow 
1 comprises sections for executing basic functions, such ^ , cPU 15 awaits an input in«nic- 

as read/write section 11, PIN setting/collating section jjo^ from card reader/writer 2 in step 43. When CPU 15 
12, and encrypting/decrypting section 13, and supervi- 35 ^^^^ instruction from card reader/writer 2 ui step 
sor 14 for controlling these basic functions. Read/wnte ^ ^p^^ jj executes processing based on the instruction 
section 11 performs data read, write, or erase access ^' ^ .j^^ gQ„,ro, advances to step 47, and 0«e 
with data memory 16. PIN setting/collating secuon 12 gg^g result is output to card reader/wnter 2. The 
performs storage and read inhibition P«>e««"f °;. " ^ how returns to step 43. FIG. 8 shows the foraat of 
PIN set by a user, and after the PIN is set, collates the 40 ^ ^ cse. As can be seen from FIG. 8, 
set PIN to provide permission for the subseqneiit pro- f^^^^ indicating a function code included m the mput 
cessing. Encrypting/decrypting section 13 performs ^^^^^^^^ attached to data field 49 indicating the 
encryption for preventing disclosure and forgeor of ^^^^ 

communication dato when data U transmitted from P ^n operation will now be described with referrace to 
CPU 3 to another tenninal through a communication 45 fj^^chart in HG. 9 wherein IC card 1 fetches an 
line, and decrypts encrypted data. Data encrypUon is ^io„ executes processing in accordance with 

peri^ormed in accordance with an encryption »\ionQm indention. When an instruction is to be sent from 

having a sufficient encryption power, such as the Data reader/writer 2 to IC card 1. start byte field 75 is 

EncrypUon Standard (DES). Supervisor 14 decodes an ^ i^itniction in addition to OP code field 

operation code (OP code) input from r««lar/- SO „ ^^^y, ,5^,^79. as shown in HG. 10. In st^51. the 
M^ter 2 or the OP code with data, and selecu and j/^^^" input instnwtion te fetched. It is 

executes a necessary funcUon. . , . ^„.,; checked in step 53 if the fetched byte te a «tMt byte. If 

In order to efl^ect these functwns, IC cwd 1 is consti- 5^'*^ q^,^ returns to step 51. If YES in step 

n,ted by central processing unit (CPU) 15, non-volaule ^O m «ep»^J^, fe.ched in step 55. In step 57, 
data mimory 16 whose storage contentt are «n^le. 55 f' by one. It is then checked 
program memory 17. and contactor 18 for «l««^n«db^ SteTM if inpu«ing of the instrtK:tion is completed. If 
Contacting card reader/writer 2. CPU 15. date m«nory rt^w ^ »P ,^ ^ However, 

16. and prognun memory ^1^?^^"^^^^^^ tf NO in st^si. it is checked in step 61 if the bj^e count 
available microprocessor chip (e.g., Intel •0'" » "« has reached a capacity limit of data memory 16. If NO 
equivalent). CPU 15 has first output buff«' 19 and «c- 60 ^J^^^^^^ J^^ to step 55. and the subse- 
Za output buffer 20. Note that the number of output m step «. other hand, if YES in step 

buffers is not limited to 2. «.j^„i„ «i the flow advances to step 63 to check if the count is 

Program memory 17 compnses a «^-°°^y £ YES U obtained in step 61 and the 

memory (ROM), and has a control program for control- °' 63. NO i^ 

ling CPU 15. The control prognmi "clud« a subrou- 65 J^t of the RAM h, this case is 32 

one group for effecting a f^'^^^^^f^^l^'? StZ^L? Kytecount has reached 32. Therefore, 
OP code of an Not "ways obLed in step 63. 

writer 2. Data memory 16 composes an eiecincaiiy iiw « »■ j 
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When the flow advances from step 59 to step 63 and 15 sets response data indicating an abnormal text in 
YES is obtained in step 63, although the input dau second output buffer 20 in step 95, and sends the re- 
ttring is completed, the byte count is "1" or less, and sponse dau set in buffer 20 to card reader/writer 2 in 
this means a substantial instruction has not been re- step 97. Thereafter, the flow returns to step 81. 
oeived and processing cannot be executed. This is be- 5 In this embodiment, two output buffers arc provided 
cause the OP code consists of 2 bytes. Therefore, if YES to IC card 1, and they arc selectively used to store 
in step 63, data **FF' (hexadecimal code) is set in OP response data when a resend-request instruction is ab- 
code field 77 in step 65, and response data indicating an normal and to store data response data including the 
illegal data-string length is output. More specifically, processed result. With this arrangement, response data 
when CPU 15 receives an instruction from card rca- 10 including the processed result to be resent cannot be 
der/writer 2 and when it discriminates that no OP code erased by setting response data indicating an abnormal 
is input, CPU 15 outputs, to card reader/writer 2, the text. 

processed result with specific daU other than the OP The operation of card reader/writer 2 will now be 

code. e.g.. a specific code "JTP* (hexadecimal code) as described with reference to the flow charts shown in 
response data. 15 ROS. 14A and 14B. CPU 23 in card reader/writer 2 

If NO in step 63, it b checked in step 67 if an abnor- sets an initial value in a sequential number in step 111, 

mal instruction such as parity abnormality is input. If and checks in step 113 if an instruction is supplied from 

YES in step 67, CPU 15 outputs response data indicat- CPU 3. If NO in step 113. CPU 23 waits until an instruc- 

ing an abnormal instruction together with the OP code tion is supplied. If YES in step 113, CPU 23 checks in 
attached thereto, and the flow returns to step 51. How- 20 step 115 if IC card 1 is busy. If YES in step 115, CPU 23 

ever, if NO in step 67, CPU 15 executes a function outputs response data indicating a multiplexed instruc- 

designated by the OP code in step 71, and outputs, to tion error to CPU 3 in step 117, and the flow returns to 

card reader/writer 2, the processed result with the OP step 113. If NO in step 115, CPU 23 appends a sequen- 

code attached thereto as response data in step 73. tial number to an instruction in step 119 and sends it to 

In the above embodiment, data exchange between 25 IC card 1. CPU 23 then checks in step 121 if response 

card reader/writer 2 and IC card 1 has been exempli- daU is supplied from IC card 1. If NO in step 121, CPU 

fied. The present invention can be applied to data ex- 23 checks in step 135 if time is up (time out). If NO in 

change between CPU 3 and card reader/writer 2. step 135, the flow returns to step 121, and CPU 23 

A second embodiment of the present invention will awaits response data from IC card 1. However, if YES 
now be described. In this embodiment, in an instruction 30 is completed in step 129, CPU 23 outputs response dau 

sent from card reader/writer 2 to IC card 1, a sequential to CPU 3 in step 133. Thereafter, the flow returns to 

number is attached to the instruction formats shown in step 113, and awaits the instruction from CPU 3. If NO 

FIGS. 6A and 6B, as shown in FIGS. IIA and IIB. A in step 127, CPU 23 outputs response data to CPU 3 in 

sequential number 10 is attached to an instruction out- step 133. Then, the flow returns to step 113, and CPU 23 
put 103 from card reader/writer 2, and IC card 1 re- 35 awaits the instruction from CPU 3. 
ceiving the instruction attaches the sequential number FIG. 15 shows a detailed transmission sequence be- 

of the received instruction to response data 107 and tween card reader/writer 2 and IC card 1. In the first 

outputs it to card reader/writer 2. transmission, card reader/writer 2 sends an instruction 

The embodiment of the present invention will be with sequential No. (1) and OP code (A) to IC card 1. 
described hereinafter with reference to the flow chart 40 IC card 1 executes processing corresponding to OP 
shown in FIG. 12. CPU 15 checks in step 81 if an in- code (A), and sends back response data including se- 
at ruction is sent from card reader/writer 2. If NO in quential No. (1), OP code (A), and processed result (a) 
step 81, CPU 15 awaits until the instruction arrives. If to card reader/writer 2. Since the response data with 
YES in step 81, it is checked in step 83 if the received sequential No. (1) is sent back from IC card 1, card 
text (instruction) is normal. More specifically, it is 45 reader/writer 2 sends an instruction with sequential No. 
checked if an OP code included in the text corresponds (2) and OP code (A) to IC card 1 in the second transmis- 
to any of predetermined OP codes or if the text includes sion. Assume that IC card 1 fails to receive the instruc- 
a parity error. If YES in step 83, CPU 15 executes pro- tion itself. In this case, for example, IC card 1 cannot 
cessing corresponding to the input instruction in step receive the start byte. Card reader/writer 2 confirms 
85, and sets the processed result in output buffer 19 in 50 that response daU corresponding to the instruction 
step 87. In step 93, CPU 15 then outputs response data when sequential No. (2) is not sent back from IC card 1. 
including the processed result set in output buffer 19 to However, card reader/writer 2 cannot decide whether 
card reader/writer 2. Then, the flow returns to step 81, IC card 1 cannot receive the instruction or card rea- 
and CPU 15 awaits the next instruction from card rca- der/writer 2 cannot receive the instruction although the 
der/writer 2. The response data which is output from 55 response data including the processed result is sent back 
CPU 15 to card reader/writer 2 in step 93 consists of from IC card 1. Therefore, card reader/writer 2 sends 
sequential number 101 attached to the instruction sent an instruction including sequential No. (3) and OP code 
from card reader/writer 2, OP code 103 attached (B) indicating a resend request to IC card 1. In the third 
thereto, processing result 105, and data 107 which is transmission, assume that IC card 1 receives the instruc- 
attacbed if necessary, as shown in FIG. 13. 60 tion with sequential No. (3) from card reader/writer 2 
On the other hand, if NO in step 83, CPU 15 checks but determines that the received text is abnormal (e.g., 
in step 89 if the instruction is a resend-request instruc- the OP code is undesirably converted to a nonregistered 
tion. If NO in step 89, CPU 15 sets response daU indi- OP code during transmission). IC card 1 sends back 
eating an abnormal text in first output buffer 19 in step response data including sequential No. (3), OP code (B) 
91, and sends the response data set in first output buffer 65 indicating the resend request, and processed result 05) 
19 to card reader/writer 2. Thereafter, the flow returns indicating an abnormal text to card reader/writer 2. 
to step 81, and CPU 15 awaits the next instruction from Upon reception of this data, card reader/writer 2 sends 
card reader/writer 2. However, if YES in step 89. CPU an instruction including sequential No. (4) and OP code 
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(B) indicating the rescnd request to IC card 1. IC card 
1 detects the rescnd-rcqucst instruction with sequential 
No. (4). Since IC card 1 could not receive an instruction 
with sequential No. (2), the latest dau set in output 
buffer 19 is the processed result corresponding to the 
insiruction with sequential No. (I). Therefore. IC card 
1 sends response data including sequential No. (1). OP 
code (A), and processed result (a) to card reader/writer 
2. Since the processed result corresponding to the in- 
ttiwrtion with sequential No. (1) is sent back from IC 
card 1, card reader/writer 2 aciids an instruction includ- 
ing sequential No. (2) and OP code (A) to IC card 1 in 
the fifth transmission. IC card 1 detects this instruction, 
and executes processing corresponding thereto. Then, 
IC card 1 sends back response data including sequential 
No. (2), OP code (A), and processed result (7) to card 
reader/writer 2. 

In the above embodiment, the IC card has been exem- 
plified as a portable electronic device. However, the 


2. A system according to claim 1, wherein the data is 
data other than the function code, consists of the same 
number of bits as the number of bits of the function 
code, and is set in said fimction code field. 
5 3. A system according to claim 1, wherein the speci- 
fied data consists of all "1" bits, and the function code is 
an arbitrary bit string consisting of not all "1" bits. 

4. A data transmission as in claim 1, wherein said 
checking contents means also includes means for count- 

10 ing a length of an input instruction data; means for 
determining if the input instruction data is completed; 
means for determining if the counted length of the input 
instruction data has reached a predetermined value, and 
for setting said data in the instruction code field 

15 when said counted Icngith does not reach said specified 
value when said input instruction data is completed. 

5. A data transmission system in which an IC card 
accepting device sends instruction data to an IC card, 
the instruction data including at least a function code in 


[bape of the^rtable electronic device is not limited to 20 « function code field nidicating a contrat ofp«>«H«"g. 

^^•^ 1 . ^ * ak.^ m^\A m r^rA r^irnififf the nmction oode m a re* 


30 


a card-like shape. The hardware arrangement of the 
poruble electronic device can be modified within the 
spirit and scope of the invention. 
What is claimed is: 

1, A daU transmission system in which in IC card 25 
accepting device sends instruction data to an IC card, 
the instruction data including in an instruction code 
field which includes at least a function code in a func- 
tion code field indicating a content of processing, and 
said IC card returning the function code in a received 
instruction dau back to said IC card accepting device, 
wherein said IC card includes: 
means for receiving the instruction data; 
means for checking contents of said instruction code 
field to determine whether the function code is a 35 
preliminarily registered fimction code; 
first returning means for setting the function code in 
the function code field and for returning the func- 
tion code field to said IC card accepting device, 
only when said checking means indicates that the 40 
function code is the preliminarily registered func- 
tion code; and 
second returning means for setting date in the func- 
tion code field indicating that the function code in 
the instruction data received by said receiving 45 
means is not the registered function code, and for 
returning the instruction code field to said IC card 
accepting device, only when said checking means 
indicates that the function code is not the regis- 
tered function code and wherein said IC card ac- 
cepting device includes: 
means for receiving the data indicating that the func- 
tion code is not sent by said second returning 


SO 


and said IC card returning the function code in a re* 
ceived instruction data back to said Ic card accepting 
device, wherein said IC card includes: 
means for receiving the iisstruction data; 
first determining means for determining whether or 
not the instruction date is received correctly by 
said receiving means; 
second determining means for determining whether 
or not the function code included in the instruction 
date is a registered function code when said first 
determining means determines that the instruction 
date is received correctly by said receiving means; 
first sending means for sending to said IC card ac- 
cepting device data indicating that the instruction 
data is received incorrectly when said first deter- 
mining means determines incorrect instruction of 
the instruction data; 
second sending means for sending to said IC card 
accepting device date indicating that the function 
code included in the instruction date is not the 
registered function code when said second deter- 
mining means determines that the function code in 
the instruction date is not the registered function 
code; and 

third sending means for sending a processed result for 
the instruction date together with the function 
code to said IC card accepting device if said first 
determining means determines the correct recep- 
tion of the instruction date and said second deter- 
mining means determines that the function oode in 
the correctly received instruction date is the regis- 
tered function code. 
6. The system according to claim 5. wherein said first 
determining means includes means for counting date 


means; and . . . 

means for in response to the function code resending 55 length of the mstruction date. ^ 
the instruction date to said IC card. 


60 
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